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

0.3.3-3-rc.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-21 14:35:57 +02:00
parent 58ecd667b0
commit 01df07d6af
8 changed files with 625 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
CHANGELOG.md
View File

@@ -1,8 +1,19 @@
<!-- file: CHANGELOG.md -->
<!-- version: 16 -->
<!-- version: 17 -->
# Changelog
## 0.3.3-3-rc.1 — 2026-09-21
- gel fonctionnel du pipeline Android SDL3 natif désormais possédé par Gradle/Cargo, sans orchestrateur Python de build ni `src/main/jniLibs` généré dans les sources ;
- APK Debug universal et AAB Release validés pour `arm64-v8a`, `armeabi-v7a`, `x86_64` et `x86`, avec `minSdk 21` conservé ;
- compatibilité pages mémoire 16 KB validée sur les ABI 64 bits, y compris smoke Android 15/API 35 x86_64 `ps16k` avec `PAGE_SIZE=16384` ;
- smoke Android 5.0/API 21 x86 validé, puis smokes beta Snake et Reflex validés sur AVD API 36 x86_64 et Samsung API 29 ARM64 sans crash immédiat ;
- environnement Android natif validé avec Temurin 25 et Gradle système 9.7.1, le projet imposant seulement `Gradle >= 9.6.0` ;
- prompt `0.3.4` préparé pour l'API de transport realtime/WebSocket et pour la migration de nomenclature à `alpha.M`, `beta.M`, `rc.M` à partir de la prochaine session uniquement ; aucun historique antérieur ne sera renommé ou réécrit.
La RC n'ouvre aucun nouveau scope. Seuls les correctifs de publication autorisés par `VER-RC-*` peuvent produire un `3-rc.1.fix.N`.
## 0.3.1 — 2026-09-21
- publication stable du second host Snake sous Tauri Android, conservé comme POC de référence et non comme voie de production Android ;

4
Cargo.toml
View File

@@ -1,5 +1,5 @@
# file: Cargo.toml
# version: 84
# version: 85
[workspace]
resolver = "3"
@@ -21,7 +21,7 @@ members = [
]
[workspace.package]
version = "0.3.3-2-beta.1"
version = "0.3.3-3-rc.1"
edition = "2024"
license = "MIT"
repository = "https://git.sasedev.com/Sasedev/games"

66
deltas/0.3.3/3-rc.1.md Normal file
View File

@@ -0,0 +1,66 @@
<!-- file: deltas/0.3.3/3-rc.1.md -->
<!-- version: 1 -->
# Delta 0.3.3-3-rc.1
## Base requise
`0.3.3-2-beta.1`, validée le 2026-09-21.
## Objectif
Créer la candidate de publication `0.3.3` sans rouvrir le scope du pipeline Android SDL3 natif multi-ABI.
## Gel RC
Le scope `0.3.3` est gelé. Cette tranche n'ajoute :
- aucune fonctionnalité ;
- aucune ABI ;
- aucune API Android ;
- aucune dépendance ;
- aucune logique Gradle/JNI/Java/Rust ;
- aucun changement de gameplay ou moteur ;
- aucune nouvelle politique de packaging.
Seuls les correctifs autorisés par `VER-RC-*` peuvent suivre sous `3-rc.1.fix.N`.
## Validation beta acquise
`2-beta.1` a validé :
- audits, formatage, check, Clippy et test workspace complet avec 35 tests réussis ;
- rebuild propre Snake/Reflex en Debug et Release ;
- quatre ABI `arm64-v8a`, `armeabi-v7a`, `x86_64`, `x86` dans APK et AAB ;
- `zipalign -P 16` sur les deux APK ;
- smokes Snake et Reflex sur AVD API 36 x86_64 avec processus vivant et aucun crash remonté ;
- smokes Snake et Reflex sur Samsung API 29 ARM64 avec processus vivant et aucun crash remonté.
Les preuves de frontière API 21/x86 et API 35/x86_64 `ps16k` avaient déjà été acquises en `0-pre.5`.
## Changements
- passage de `workspace.package.version` à `0.3.3-3-rc.1` ;
- entrée RC dans `CHANGELOG.md` ;
- ajout de `history/0.3.3/2-beta.1.md` ;
- ajout de `docs/testing/006-V0_3_3_RC_VALIDATION_MATRIX.md` et de son index ;
- consolidation du plan `0.3.3` avec la gate beta réellement obtenue ;
- création de `prompts/005-V0_3_4_START_PROMPT.md`.
La nouvelle nomenclature de versions approuvée par l'utilisateur n'est **pas** appliquée dans cette session : `0.3.3` termine sous l'ancien schéma. Le prompt `0.3.4` prépare la migration des règles actives vers `alpha.M / beta.M / rc.M` dès la prochaine session, avec interdiction de renommer ou réécrire les anciens `deltas/`, `history/`, changelog ou prompts historiques.
`ROADMAP.md` reste inchangé : le statut macro de `0.3.3` ne devient terminé qu'à la stable.
## Validation RC
Appliquer intégralement :
```text
docs/testing/006-V0_3_3_RC_VALIDATION_MATRIX.md
```
La gate revalide workspace, APK/AAB quatre ABI, packaging 16 KB 64 bits et les smokes de publication x86_64 + ARM64. Elle exige aussi une observation humaine finale du rendu et des contrôles Snake/Reflex.
## Après validation
Si la RC est propre, la promotion vers `0.3.3` est mécanique : version stable, entrée stable du changelog, historique RC, clôture du plan et delta de release. Aucun nouveau comportement ne doit être introduit.

3
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 30 -->
<!-- version: 31 -->
# Documentation games.sasedev
@@ -72,6 +72,7 @@ Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](ru
- [`testing/003-RC_VALIDATION_MATRIX.md`](testing/003-RC_VALIDATION_MATRIX.md) — matrice RC de reproductibilité, packaging final et promotion vers `0.1.0`.
- [`testing/004-V0_3_0_RC_VALIDATION_MATRIX.md`](testing/004-V0_3_0_RC_VALIDATION_MATRIX.md) — gate RC spécifique au POC Snake Web direct et à son témoin Desktop SDL3.
- [`testing/005-V0_3_1_RC_VALIDATION_MATRIX.md`](testing/005-V0_3_1_RC_VALIDATION_MATRIX.md) — gate RC du POC Snake Tauri Android de référence, incluant workspace complet et APK universal x86_64 + ARM64.
- [`testing/006-V0_3_3_RC_VALIDATION_MATRIX.md`](testing/006-V0_3_3_RC_VALIDATION_MATRIX.md) — gate RC du pipeline Android SDL3 natif quatre ABI, APK/AAB, 16 KB et smokes x86_64 + ARM64.
- [`development/003-TRACING_AND_DIAGNOSTICS.md`](development/003-TRACING_AND_DIAGNOSTICS.md) — socle `tracing`, subscriber et appender communs.
- [`development/004-SDL3_DESKTOP_PREREQUISITES.md`](development/004-SDL3_DESKTOP_PREREQUISITES.md) — prérequis SDL3 Desktop, stratégie de liaison système et vérification `pkg-config`.
- [`development/005-DESKTOP_WINDOW_POLICY.md`](development/005-DESKTOP_WINDOW_POLICY.md) — taille initiale, redimensionnement et séparation future entre fenêtre physique et résolution virtuelle.

8
docs/plans/003-V0_3_3_ANDROID_NATIVE_MULTI_ABI_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_3_3_ANDROID_NATIVE_MULTI_ABI_PLAN.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# Plan 0.3.3 — Android SDL3 natif multi-ABI et packaging Gradle
@@ -178,7 +178,11 @@ Corriger uniquement par `2-beta.1.fix.N` si nécessaire ; ne pas ouvrir une beta
### `3-rc.1` — gel et reproductibilité
Geler le scope, consolider `CHANGELOG.md`, documentation finale, historique beta, matrice RC et prompt de la prochaine version. Rejouer uniquement les gates de publication/reproductibilité prévues ; aucune nouvelle capacité.
La beta a passé la gate workspace complète, 35 tests, les rebuilds Debug/Release quatre ABI, l'inspection APK/AAB, `zipalign -P 16` et les smokes Snake/Reflex sur AVD API 36 x86_64 ainsi que Samsung API 29 ARM64. Aucun `2-beta.1.fix.N` n'est requis.
Geler le scope, consolider `CHANGELOG.md`, l'historique beta, la matrice RC et le prompt `0.3.4`. Rejouer uniquement les gates de publication/reproductibilité prévues ; aucune nouvelle capacité.
La convention de prerelease reste inchangée jusqu'à la stable `0.3.3`. La migration approuvée vers `X.Y.Z-alpha.M`, `X.Y.Z-beta.M`, `X.Y.Z-rc.M` et leurs `.fix.N` commence seulement dans la session `0.3.4`. Elle modifie les règles actives et les audits à partir de cette nouvelle version, sans renommer ni réécrire aucun ancien fichier sous `deltas/`, `history/` ou les anciennes entrées du changelog.
### `0.3.3` — stable

151
docs/testing/006-V0_3_3_RC_VALIDATION_MATRIX.md Normal file
View File

@@ -0,0 +1,151 @@
<!-- file: docs/testing/006-V0_3_3_RC_VALIDATION_MATRIX.md -->
<!-- version: 1 -->
# Matrice de validation RC 0.3.3
## Objectif
`0.3.3-3-rc.1` est une candidate gelée. Elle ne modifie ni gameplay, ni moteur, ni JNI, ni Java, ni logique Gradle : elle revalide qu'un état reproductible du pipeline Android SDL3 natif peut être promu mécaniquement vers `0.3.3`.
## Gel fonctionnel
Pendant `3-rc.*`, seules les corrections autorisées par `VER-RC-*` sont admises. Toute nouvelle ABI, nouvelle API Android, nouvelle capability réseau, nouvelle abstraction, refactor volontaire ou changement de comportement est hors scope.
La future convention de versions `alpha.M / beta.M / rc.M` n'est pas appliquée à `0.3.3`; elle commencera avec la prochaine version et ne doit provoquer aucune réécriture de l'historique.
## Gate workspace
Depuis la racine :
```bash
cargo fmt --all
cargo fmt --all -- --check
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android Web deltas history
python3 scripts/audit_distribution_layout.py
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-targets --all-features
```
La suite workspace complète est répétée en RC parce que la version Cargo passe à `0.3.3-3-rc.1`.
## Rebuild Android propre
```bash
(cd Android && gradle :game-snake-poc:clean :game-reflex-poc:clean)
(cd Android && gradle :game-snake-poc:assembleDebug)
(cd Android && gradle :game-reflex-poc:assembleDebug)
(cd Android && gradle :game-snake-poc:bundleRelease)
(cd Android && gradle :game-reflex-poc:bundleRelease)
```
Le build doit utiliser le JDK normal de l'environnement et un Gradle système `>= 9.6.0`; aucun `JAVA_HOME` spécifique au projet et aucun wrapper Gradle natif ne sont requis.
## Contrôle quatre ABI
```bash
for game in game-snake-poc game-reflex-poc; do
APK="Android/${game}/build/outputs/apk/debug/${game}-debug.apk"
AAB="Android/${game}/build/outputs/bundle/release/${game}-release.aab"
test -f "$APK"
test -f "$AAB"
for abi in arm64-v8a armeabi-v7a x86_64 x86; do
unzip -Z1 "$APK" | grep -Fx "lib/${abi}/libSDL3.so"
unzip -Z1 "$APK" | grep -Fx "lib/${abi}/libgame_android_entrypoint.so"
unzip -Z1 "$AAB" | grep -Fx "base/lib/${abi}/libSDL3.so"
unzip -Z1 "$AAB" | grep -Fx "base/lib/${abi}/libgame_android_entrypoint.so"
done
done
```
## Packaging 16 KB
```bash
ZIPALIGN="$(find "$ANDROID_HOME/build-tools" -mindepth 2 -maxdepth 2 -type f -name zipalign -print | sort -V | tail -n 1)"
test -x "$ZIPALIGN"
"$ZIPALIGN" -c -P 16 -v 4 Android/game-snake-poc/build/outputs/apk/debug/game-snake-poc-debug.apk
"$ZIPALIGN" -c -P 16 -v 4 Android/game-reflex-poc/build/outputs/apk/debug/game-reflex-poc-debug.apk
```
Recontrôler les segments ELF 64 bits Release :
```bash
OBJDUMP="$ANDROID_HOME/ndk/28.2.13676358/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-objdump"
test -x "$OBJDUMP"
for game in game-snake-poc game-reflex-poc; do
for abi in arm64-v8a x86_64; do
for so in \
"Android/${game}/build/generated/sasedevNative/release/${abi}/jniLibs/${abi}/libSDL3.so" \
"Android/${game}/build/generated/sasedevNative/release/${abi}/jniLibs/${abi}/libgame_android_entrypoint.so"; do
test -f "$so"
"$OBJDUMP" -p "$so" | grep 'LOAD'
done
done
done
```
Chaque ligne `LOAD` des ABI 64 bits doit rester au minimum à `align 2**14`. Les ABI 32 bits restent supportées mais ne sont pas soumises à ce critère Play 16 KB.
## Smoke AVD API 36 x86_64
Avec l'AVD de référence déjà disponible, utiliser son serial ADB, actuellement `emulator-5554` lorsqu'il est lancé. Pour chaque jeu :
```bash
SERIAL=emulator-5554
APK=Android/game-snake-poc/build/outputs/apk/debug/game-snake-poc-debug.apk
adb -s "$SERIAL" install -r "$APK"
adb -s "$SERIAL" shell am force-stop com.sasedev.games.snake
adb -s "$SERIAL" logcat -c
adb -s "$SERIAL" shell am start -W -n com.sasedev.games.snake/.SnakeActivity
sleep 3
adb -s "$SERIAL" shell pidof com.sasedev.games.snake
adb -s "$SERIAL" logcat -d -b crash
```
Puis :
```bash
SERIAL=emulator-5554
APK=Android/game-reflex-poc/build/outputs/apk/debug/game-reflex-poc-debug.apk
adb -s "$SERIAL" install -r "$APK"
adb -s "$SERIAL" shell am force-stop com.sasedev.games.reflex
adb -s "$SERIAL" logcat -c
adb -s "$SERIAL" shell am start -W -n com.sasedev.games.reflex/.ReflexActivity
sleep 3
adb -s "$SERIAL" shell pidof com.sasedev.games.reflex
adb -s "$SERIAL" logcat -d -b crash
```
Vérifier humainement : rendu visible, assets présents, Snake réagit au swipe, Reflex réagit au tap, puis absence de crash immédiat.
## Smoke ARM64 réel
Sur le Samsung ou un autre appareil ARM64 disponible, remplacer `<serial>` :
```bash
SERIAL=<serial>
adb -s "$SERIAL" shell getprop ro.build.version.sdk
adb -s "$SERIAL" shell getprop ro.product.cpu.abi
```
Rejouer les deux blocs Snake/Reflex précédents avec `SERIAL=<serial>`. Vérifier humainement rendu, tactile et sortie/Back.
## Frontières non rejouées par défaut
Les smokes API 21/x86 et API 35/x86_64 `ps16k` ont été établis en `0-pre.5`, puis aucune logique native/Gradle n'a changé. Ils ne sont pas répétés en RC sauf si un correctif RC touche le pipeline Android, le NDK, SDL3, les ABI, `minSdk`, le packaging ou les bibliothèques natives.
## Promotion stable
Si cette gate est propre et qu'aucun correctif n'est nécessaire, la promotion vers `0.3.3` est mécanique : version stable, entrée stable du changelog, historique RC, clôture du plan, delta de release et mise à jour mécanique du prompt `0.3.4` si la base stable doit être rendue certaine. Aucun code fonctionnel ne doit changer.

118
history/0.3.3/2-beta.1.md Normal file
View File

@@ -0,0 +1,118 @@
<!-- file: history/0.3.3/2-beta.1.md -->
<!-- version: 1 -->
# Historique 0.3.3-2-beta.1
## Statut
`0.3.3-2-beta.1` a été validée par l'utilisateur le 2026-09-21. La gate large confirme la reproductibilité du pipeline Android SDL3 natif quatre ABI, les artefacts APK/AAB et les smokes de référence x86_64 + ARM64 pour Snake et Reflex.
Aucun `2-beta.1.fix.N` n'est requis. La version peut entrer directement en `0.3.3-3-rc.1`.
## Gate workspace
Les validations suivantes sont propres :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 251 file(s))
Distribution layout audit: clean (49 required path(s), 8 forbidden path(s) absent)
cargo fmt --all: clean
cargo fmt --all -- --check: clean
cargo check --workspace: clean
cargo clippy --workspace --all-targets --all-features -- -D warnings: clean
cargo test --workspace --all-targets --all-features: 35 passed, 0 failed
```
## Rebuild Android quatre ABI
Après nettoyage Gradle des deux applications, les builds suivants terminent avec succès :
```text
:game-snake-poc:assembleDebug
:game-reflex-poc:assembleDebug
:game-snake-poc:bundleRelease
:game-reflex-poc:bundleRelease
```
Pour Snake et Reflex, les tâches natives ont reconstruit les quatre cibles :
```text
arm64-v8a -> aarch64-linux-android
armeabi-v7a -> armv7-linux-androideabi
x86 -> i686-linux-android
x86_64 -> x86_64-linux-android
```
## Inspection APK et AAB
Chaque APK Debug contient :
```text
lib/<abi>/libSDL3.so
lib/<abi>/libgame_android_entrypoint.so
```
pour les quatre ABI. Chaque AAB Release contient les mêmes couples sous `base/lib/<abi>/`.
`zipalign -c -P 16 -v 4` retourne `Verification successful` pour les APK Debug Snake et Reflex.
## Smokes x86_64/API 36
L'AVD de référence rapporte :
```text
API 36
x86_64
PAGE_SIZE 4096
```
Snake :
```text
install: Success
Status: ok
LaunchState: COLD
pidof: 5192
crash buffer: aucune entrée remontée
```
Reflex :
```text
install: Success
Status: ok
LaunchState: COLD
pidof: 5272
crash buffer: aucune entrée remontée
```
## Smokes ARM64 réels
Le Samsung `SM_G965F` rapporte :
```text
API 29
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
```
Snake : installation `Success`, `Status: ok`, lancement COLD et processus vivant (`pidof 30958`).
Reflex : installation `Success`, `Status: ok`, lancement COLD et processus vivant (`pidof 31798`).
Aucune entrée du buffer crash n'a été remontée pendant ces quatre smokes. Les sorties ADB établissent le démarrage et l'absence de crash immédiat ; la matrice RC conserve explicitement la vérification visuelle du rendu et des contrôles comme dernière observation humaine de publication.
## Frontières déjà acquises en 0-pre.5
Aucune logique Android/native n'ayant changé depuis les preuves de frontière, la beta réutilise sans les rejouer systématiquement :
- Android 5.0/API 21 x86 : APK Snake installé et activité démarrée ;
- Android 15/API 35 x86_64 `ps16k` : `getconf PAGE_SIZE=16384`, APK installé, activité démarrée et processus vivant ;
- ELF `arm64-v8a` et `x86_64` alignés `2**14` pour SDL3 et la bibliothèque Rust.
## Conclusion
Le scope d'implémentation reste fermé. `3-rc.1` peut être une candidate strictement gelée, centrée sur la reproductibilité finale, la documentation de publication et la préparation de la session suivante.

268
prompts/005-V0_3_4_START_PROMPT.md Normal file
View File

@@ -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.