games/docs/studies/024-V0_3_1_TAURI_ANDROID_SNAKE_AUDIT.md

Audit v0.3.1 — second host Snake Tauri Android

Statut

Étude de cadrage 0.3.1-0-pre.1.

Base autoritaire : archive téléchargée depuis le tag v0.3.0 et fournie pour cette reprise.

Cette tranche reste un gate d'audit, requirements, sizing et planification. Aucun scaffold Tauri Android Snake, aucun frontend nouveau et aucun changement de gameplay n'y sont introduits.

Intégrité de la baseline

L'archive v0.3.0 a été extraite et testée avant modification.

Les contrôles statiques de baseline sont propres :

unzip -t : no errors
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 197 file(s))
Distribution layout audit: clean (31 required path(s), 1 forbidden path(s) absent)

La version technique racine est 0.3.0. Aucun Cargo.lock, package-lock.json, pnpm-lock.yaml, yarn.lock, node_modules/, dist/, target/ ou binding WASM généré n'est présent dans l'archive source.

L'absence de .git est normale pour cette archive taggée et ne permet ni ne requiert d'inventer un état Git.

État fonctionnel hérité

La release 0.3.0 apporte déjà les briques nécessaires au second host :

• game-snake-poc porte le gameplay et reste indépendant du host ;
• game-snake-poc-wasm expose le runtime Snake à WebAssembly ;
• Web/game-snake-poc valide Canvas, clavier/pointer/touch, resize, lifecycle navigateur, assets, diagnostics frontend et provenance ;
• le runner Desktop SDL3 reste le témoin natif de non-régression ;
• les builds Web nouveaux utilisent Cargo, wasm-bindgen et Vite sans orchestration Python.

Le POC Tauri Reflex historique fournit en plus une référence de structure Tauri, mais il conserve des hooks Python gelés qui ne doivent pas être copiés dans un chemin 0.3.x.

Son manifest contient déjà le triplet crate-type = ["staticlib", "cdylib", "rlib"], compatible avec la préparation mobile Tauri. En revanche son run() reste un point d'entrée Desktop et n'est pas annoté #[cfg_attr(mobile, tauri::mobile_entry_point)]. La nouvelle app Snake doit donc reprendre la séparation de fichiers, pas ce détail Desktop : le run() possédé par tauri.rs devra être le point d'entrée mobile et être réexporté par la façade lib.rs.

Le manifest Reflex déclare aussi engine-v1-platform-api, alors que son code source Tauri ne le consomme pas directement. Cette dépendance ne doit pas être copiée par mimétisme dans la nouvelle app ; la provenance Snake appartient déjà à l'adapter WASM tant qu'aucune responsabilité backend Tauri ne justifie ce lien.

Référence KSP Desk

L'archive de référence KSP khadhroony-solana-project-v0.3.15.zip est bien présente dans la bibliothèque du projet, mais son export binaire vers l'environnement de travail n'est pas autorisé par la bibliothèque. Son contenu intégral n'est donc pas présenté comme audité ici.

Les éléments KSP indexés accessibles confirment néanmoins la convention recherchée :

• src/tauri.rs concentre l'assemblage Tauri et le lifecycle de fenêtre ;
• des modules propriétaires tels que app_state.rs, route_runtime.rs et frontend_logging.rs portent leur logique au lieu de gonfler tauri.rs ;
• les diagnostics frontend sont routés vers des cibles tracing structurées.

Le modèle normatif de games.sasedev reste la source de vérité : lib.rs façade/reexports, tauri.rs assemblage et pont Web/Rust, modules propriétaires séparés.

Réutilisation attendue du host Web

Réutilisé sans changement de responsabilité

game-snake-poc reste inchangé comme source de vérité du gameplay.

Les assets canoniques sous assets/common/ et assets/game-snake-poc/ restent les mêmes ; le host Tauri doit les embarquer ou les copier au build, pas créer une seconde source.

Le contrat sémantique d'entrée du jeu reste le même. Les boutons tactiles et éventuelles entrées clavier du WebView convergent vers les mêmes actions Snake.

Réutilisé avec adaptation de host

Le Canvas, la session fixed-step, la projection de scène et une grande partie du shell Vite/TypeScript du host Web sont des références directes pour le frontend Tauri.

La détection DeviceClass et InputProfile peut être reprise, mais les dimensions fixes de provenance changent :

Web direct      = Web / Wasm / Browser
Tauri Android   = Android / Wasm / TauriWebView

Le lifecycle navigateur visibilitychange/pagehide/pageshow n'est pas copié comme seul contrat mobile. Le host Tauri Android doit tester le comportement réel lors de pause/reprise, changement d'orientation, background/foreground et fermeture/navigation système.

Le logging frontend Web direct n'est pas réutilisé tel quel : Tauri doit utiliser le bridge @fltsci/tauri-plugin-tracing vers tauri-plugin-tracing/tracing.

Dépendances frontend à ne pas copier mécaniquement

Bootstrap, Bootswatch, Font Awesome et Sass peuvent être repris si le shell Tauri conserve réellement la même UI.

SimpleBar et resize-observer-polyfill restent des dépendances du shell Web direct ; les règles interdisent de les faire devenir des dépendances Tauri par simple copie. Elles ne seront ajoutées que si le layout Android Tauri démontre leur nécessité.

Point de friction principal : provenance de l'adapter WASM

game-snake-poc-wasm est réutilisable pour le gameplay et le rendu, mais son état 0.3.0 fixe actuellement PlatformFamily::Web et RuntimeHost::Browser dans son constructeur et dans configure_runtime_provenance.

Il ne peut donc pas décrire correctement un WebView Tauri Android sans modification minimale.

La direction retenue est de généraliser uniquement la configuration de provenance du host dans l'adapter existant, sans dupliquer le bridge et sans créer une abstraction WebView commune prématurée. Le même adapter doit pouvoir représenter au moins :

Web / Browser / Wasm
Android / TauriWebView / Wasm

Le nom PlatformFamily::Android est conservé. Mobile reste une famille conceptuelle d'architecture et ne justifie pas un renommage de l'API V1 ni l'introduction d'iOS dans 0.3.1.

Structure cible de l'application

Le second host sera une nouvelle crate :

crates/apps/game-snake-poc-tauri/

La crate est génériquement nommée Tauri afin de pouvoir accueillir ultérieurement le host Desktop prévu en 0.3.2, mais 0.3.1 n'en valide que la cible Android.

Structure minimale visée :

crates/apps/game-snake-poc-tauri/
├── Cargo.toml
├── build.rs
├── tauri.conf.json
├── capabilities/
├── frontend/
├── src/
│   ├── lib.rs
│   ├── main.rs
│   ├── runtime.rs
│   └── tauri.rs
├── README.md
└── USAGE.md

lib.rs reste une façade. tauri.rs assemble builder/plugins/commands et délègue aux modules propriétaires. Une responsabilité supplémentaire devient un module dédié plutôt qu'une collection de helpers dans tauri.rs.

Le README.md est requis pour expliquer frontières et architecture. USAGE.md est également retenu car le host Android Tauri possède des prérequis SDK/JDK/NDK, des commandes de device/AVD et des smokes non triviaux.

Build et commandes Tauri Android

La revue des règles a trouvé un défaut de cible : les commandes Tauri existantes cargo tauri dev/build correspondent au chemin Desktop alors que le nouveau POC est mobile Android.

La règle est corrigée pour réserver à Android :

cargo tauri android init
cargo tauri android dev
cargo tauri android build

Le projet mobile généré par Tauri est traité comme partie du host Android lorsqu'il est requis par l'outil ; son contenu exact sera créé par l'outil Tauri dans la tranche d'implémentation, pas fabriqué à la main pendant le cadrage.

Aucun nouveau script Python de build n'est autorisé. Le frontend Vite/TypeScript et la génération WASM doivent rester possédés par les hooks Tauri et les outils natifs Cargo/wasm-bindgen/Tauri.

Environnement Android : confirmé et à reconfirmer

L'historique du dépôt prouve des validations récentes de l'autre chemin Android SDL3 : NDK, ADB, AVD API 36 et appareil ARM64 réel ont déjà été utilisés avec succès pendant 0.1.0.

La release 0.3.0 prouve également l'usage récent de Cargo, wasm32-unknown-unknown, wasm-bindgen, Node/npm et Vite.

Ces validations historiques ne prouvent pas l'état présent du toolchain Tauri Android. Avant 0-pre.2, l'utilisateur doit fournir un inventaire frais de :

• cargo tauri --version ;
• targets Rust Android installés ;
• Java/JDK et JAVA_HOME ;
• ANDROID_HOME ;
• NDK et NDK_HOME ;
• adb version et devices visibles ;
• AVD disponibles ;
• Node/npm et wasm-bindgen.

Les prérequis Tauri 2 actuels pour Android comprennent Android Studio/tooling SDK, NDK, JDK et les targets Rust Android. Cette tranche ne suppose pas qu'ils sont tous encore configurés seulement parce que l'Android SDL3 historique fonctionnait.

Risques à tester explicitement

• compatibilité réelle de tauri-plugin-tracing et du bridge frontend sur Android ; le package 0.3.x est bien la référence actuelle du projet, mais le support mobile doit être prouvé par compilation/smoke plutôt que supposé ;
• lifecycle background/foreground et suspension du WebView ;
• distinction entre une sortie applicative Tauri, qui passe par EngineGame::quit_requested, et le Back système Android, qui ne doit pas être consommé artificiellement ;
• propagation correcte des dimensions logiques et du devicePixelRatio après rotation/resize ;
• chargement des assets embarqués sans dépendre du serveur Vite en build Android ;
• pipeline WASM sans script Python ;
• séparation claire entre Android SDL3 existant sous Android/ et Tauri Android généré par la crate Tauri ;
• absence de dépendances Web-only recopiées par inertie ;
• output des builds et caches hors racine selon GAME-BUILD-001.

Décisions de cadrage

Retenu pour 0.3.1 :

• une seule nouvelle app game-snake-poc-tauri ;
• Android uniquement comme cible validée dans cette version ;
• réutilisation du même game-snake-poc-wasm après généralisation minimale de provenance ;
• réutilisation sélective du frontend Web ;
• structure Rust Tauri conforme aux apps Desk : façade, assemblage, modules propriétaires ;
• tracing Tauri de bout en bout ;
• pas de nouveau framework commun tant qu'une duplication réelle entre Web direct et Tauri WebView n'est pas mesurée ;
• aucun orchestrateur Python nouveau ou repris.

Reporté :

• Tauri Desktop Snake comme produit validé, vers 0.3.2 ;
• abstraction WebView commune, sauf duplication réellement prouvée ;
• iOS ;
• Android SDL3 multi-ABI supplémentaire ;
• ads, billing, auth, réseau realtime et Uroburas.

Sizing

Le scope complet est trop risqué pour être comprimé dans une seule prerelease d'implémentation. Le découpage retenu est :

0-pre.1  audit / règles / requirements / environnement / plan
0-pre.2  scaffold Tauri Android + pipeline natif + bridge minimal vers Snake WASM
0-pre.3  Canvas / input / assets / shell réutilisé du Web
0-pre.4  lifecycle / provenance / tracing / Back + smoke mobile
0-pre.5  conditionnel : extraction commune seulement si duplication réelle
2-beta.1 gate large + packaging Android + AVD/appareil selon disponibilité
2-beta.2 consolidation documentaire si nécessaire
3-rc.1   candidate gelée et reproductibilité
0.3.1    promotion stable mécanique

Une tranche peut être scindée si un défaut outillage réel l'impose. 0-pre.5 est supprimé s'il n'existe aucune extraction justifiée.