games/docs/plans/002-V0_3_1_TAURI_ANDROID_SNAKE_PLAN.md

Plan v0.3.1 — second host Snake Tauri Android

But de la version

0.3.1 doit ajouter un second host Snake réellement exécutable sous Tauri Android en réutilisant la baseline Web/WASM validée par 0.3.0.

La version ne doit ni déplacer le gameplay hors de game-snake-poc, ni créer un second adapter Snake, ni transformer immédiatement les similitudes Web/Tauri en framework générique.

Base stable : 0.3.0.

Cadrage : ../studies/024-V0_3_1_TAURI_ANDROID_SNAKE_AUDIT.md.

Décisions acquises

• la nouvelle crate sera crates/apps/game-snake-poc-tauri ;
• 0.3.1 valide uniquement sa cible Android ;
• game-snake-poc reste inchangé sauf défaut réellement découvert ;
• game-snake-poc-wasm reste l'unique adapter Snake WASM et recevra seulement la généralisation de provenance nécessaire au second host ;
• le frontend Tauri part du comportement réellement validé dans Web/game-snake-poc, avec adaptation de lifecycle et logging ;
• lib.rs est une façade/reexport et tauri.rs reste l'assemblage Tauri ;
• le tracing frontend utilise @fltsci/tauri-plugin-tracing ;
• les hooks Tauri possèdent le build frontend/WASM ;
• aucun nouveau chemin de build n'est piloté par Python ;
• README.md et USAGE.md seront créés avec l'app : architecture pour le premier, prérequis/commandes/smokes pour le second ;
• cargo tauri android init/dev/build sont les commandes mobiles de référence ;
• SimpleBar et resize-observer-polyfill ne sont pas ajoutés au host Tauri sans besoin démontré.

Scope

La version couvre :

• création de la crate/app Tauri Snake ;
• initialisation de la cible Android par Tauri ;
• pipeline Rust/WASM + Vite/TypeScript possédé par Tauri sans Python ;
• consommation de game-snake-poc-wasm ;
• shell Canvas, contrôles touch et comportement responsive nécessaires au jeu ;
• assets communs et spécifiques Snake ;
• lifecycle mobile/WebView ;
• provenance Android / Wasm / TauriWebView ;
• tracing Rust/Tauri/frontend ;
• politique de sortie/Back conforme au moteur ;
• build/package et smoke sur AVD/appareil disponible aux jalons prévus ;
• comparaison du code Web direct/Tauri après fonctionnement réel afin de décider s'il existe une extraction commune justifiée.

Hors scope : Tauri Desktop Snake comme cible validée, iOS, Android SDL3 multi-ABI additionnel, réseau realtime, Uroburas, ads, billing, auth et leaderboard.

Prévision souple

0-pre.1 — cadrage et règles

Audit complet de l'archive stable, règles, baseline Web/WASM, Tauri Reflex, références Desk KSP accessibles, environnement Android historique et commandes Tauri mobiles actuelles.

Livraison : étude 024, présent plan, correction des règles Tauri Android, clarification PlatformFamily, index documentaires et ouverture de la version technique 0.3.1-0-pre.1.

Aucun scaffold Tauri Snake n'est créé. Tranche validée par la gate utilisateur du 2026-09-20.

0-pre.2 — host Tauri Android minimal

Créer game-snake-poc-tauri avec :

• manifest Cargo/build script/config Tauri/capabilities ;
• lib.rs façade, tauri.rs assemblage et modules propriétaires minimaux ;
• point d'entrée run() mobile annoté #[cfg_attr(mobile, tauri::mobile_entry_point)] dans le module propriétaire puis réexporté par lib.rs ;
• frontend Vite/TypeScript minimal ;
• bridge tracing initialisé ;
• hooks de build natifs, sans Python ;
• cible Android initialisée via Tauri ;
• chargement du même adapter game-snake-poc-wasm après généralisation minimale de provenance ;
• README.md et USAGE.md initiaux.

La tranche vise un premier démarrage Tauri Android minimal, pas encore toute la finition input/lifecycle.

État candidat livré : crate game-snake-poc-tauri, bridge Rust/Tauri, hooks WASM/Vite sans Python, frontend minimal, tracing frontend/Rust et provenance partagée Android / TauriWebView / Wasm. L'initialisation générée cargo tauri android init reste volontairement locale et fait partie de la gate utilisateur, car gen/ n'est pas un artefact source distribué.

Gate utilisateur : audits, Cargo workspace strict, test ciblé de l'adapter WASM, non-régression du build Web direct, cargo tauri android init puis cargo tauri android dev sur un AVD ou appareil disponible. cargo tauri android build reste reporté aux phases finales sauf besoin diagnostique.

Le premier smoke 0-pre.2 a révélé deux défauts bornés : build.rs échouait sous Clippy strict à cause de la rustdoc manquante, et Java 25 ne pouvait pas exécuter le wrapper Gradle 8.14.3 généré par Tauri CLI 2.11.3. 0-pre.2.fix.1 a tenté de migrer localement le scaffold généré vers Gradle 9 ; cette approche est abandonnée par 0-pre.2.fix.2 car la branche stable Tauri 2.11.x n'a pas encore publié cette migration et le projet ne doit pas maintenir un fork implicite des templates Android Tauri. Le fix utilise donc la chaîne Android générée officiellement par Tauri stable et impose pour les commandes Android un JAVA_HOME compatible, de préférence le JBR fourni par Android Studio. Le Gradle global de la machine ne fait pas partie du contrat reproductible.

0-pre.3 — shell Snake, Canvas, input et assets

Réutiliser sélectivement le host Web validé :

• rendu Canvas et session fixed-step ;
• shell responsive pertinent ;
• contrôles directionnels touch/pointer et clavier lorsque disponible ;
• resize/orientation ;
• assets canoniques communs + Snake ;
• absence de dépendances Web-only inutiles.

Aucune extraction commune n'est réalisée uniquement pour éviter quelques fichiers similaires pendant la mise au point.

0-pre.4 — lifecycle, provenance, tracing et sortie mobile

Stabiliser :

• background/foreground et reprise sans rattrapage massif ;
• rotation/resize ;
• provenance Android / Wasm / TauriWebView + device/input observés ;
• tracing Rust/Tauri/frontend ;
• sorties applicatives conformes à EngineGame::quit_requested sans détourner le Back système Android ;
• smokes AVD et, si disponible, appareil réel.

Cette tranche doit rendre le second host fonctionnel de bout en bout.

0-pre.5 — extraction conditionnelle

Créer uniquement si l'état 0-pre.4 montre une duplication réellement durable entre Web/game-snake-poc et le frontend Tauri.

Une extraction possible doit rester bornée à une responsabilité clairement partagée, par exemple projection/rendu Canvas, mapping input Web ou helpers d'assets. Lifecycle et logging restent host-specific s'ils divergent réellement.

Si aucune extraction n'est justifiée, cette tranche est omise.

2-beta.1 — validation large et packaging Android

Prévoir :

• audits statiques applicables ;
• cargo fmt --all -- --check ;
• cargo check --workspace ;
• Clippy workspace strict ;
• suite workspace complète à ce jalon planifié ;
• build WASM release et bindings ;
• cargo tauri android build ;
• APK/AAB selon le livrable de validation ;
• install/smoke AVD ;
• install/smoke appareil ARM64 réel si disponible ;
• vérification que les outputs restent hors racine du dépôt lorsqu'ils sont configurables par le projet.

2-beta.2 — consolidation documentaire conditionnelle

Réserver seulement si les validations beta demandent une consolidation substantielle de README.md, USAGE.md, architecture, matrice de validation ou plan. Ne pas créer cette tranche par cérémonial.

3-rc.1 — candidate gelée

Gel fonctionnel, reproductibilité, packaging Android RC et validation finale selon les règles RC applicables. Aucun nouveau framework ni nouveau host.

0.3.1 — release stable

Promotion mécanique de la RC validée : versions stables, changelog, history et clôture du plan. Aucun ajout fonctionnel.

Inventaire environnement requis avant 0-pre.2

La gate 0-pre.1 doit recevoir au minimum :

rustc --version
cargo --version
cargo tauri --version
rustup target list --installed
node --version
npm --version
wasm-bindgen --version
java -version
printf 'JAVA_HOME=%s\nANDROID_HOME=%s\n' "$JAVA_HOME" "$ANDROID_HOME"
adb version
adb devices -l
emulator -list-avds

L'absence d'un outil ne doit pas être masquée. Elle devient un prérequis concret de 0-pre.2 ou motive un fix borné de 0-pre.1.

La gate 0-pre.1 validée le 2026-09-20 a confirmé Rust 1.94.1, Tauri CLI 2.11.3, Node 24.21.0, npm 11.19.0, wasm-bindgen 0.2.128, OpenJDK 25.0.4.1, ANDROID_HOME=/home/sinus/DEV/AndroidSDK, un appareil ARM64 réel et trois AVD disponibles. JAVA_HOME était vide et Java 25 était résolu depuis le PATH. Le smoke 0-pre.2 a confirmé que Tauri sélectionne lui-même le NDK side-by-side sous $ANDROID_HOME/ndk/<version> et injecte NDK_HOME dans ses sous-processus ; le défaut observé concernait Java 25 face au wrapper Gradle 8.14.3. Pour les commandes Android Tauri 2.11.x, JAVA_HOME doit donc pointer vers un JDK compatible, de préférence le JBR fourni par Android Studio.

Critères de fermeture de 0.3.1

La version peut entrer en RC lorsque :

• Snake est jouable dans le WebView Tauri Android sans gameplay dupliqué ;
• le même adapter WASM sert Web direct et Tauri Android avec provenance exacte ;
• lifecycle/input/assets/tracing/Back ont un comportement explicite et validé ;
• le chemin de build ne dépend d'aucun orchestrateur Python ;
• le packaging Tauri Android est reproductible ;
• les smokes prévus sur cible Android ont été exécutés ;
• aucune extraction commune non prouvée n'a été introduite ;
• la documentation opérateur et architecture reflète l'état réel.

Version suivante

0.3.2 reste réservée à Tauri Desktop + Snake et à une éventuelle factorisation WebView seulement après deux consommateurs réels.