Prompt de démarrage 0.3.1 — second host Snake Tauri Android

Partir de la version stable 0.3.0. Si ce prompt est lu avant la publication effective de 0.3.0, ne pas ouvrir 0.3.1 : terminer d'abord la RC et la release stable.

Lire intégralement RULES.md, ROADMAP.md, CHANGELOG.md, docs/000-README.md, docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md, docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md, docs/plans/ et le dernier historique validé de 0.3.0 avant toute proposition.

Mission

0.3.1 doit produire le second host Snake : Tauri Android. Le but est d'éprouver la réutilisation de la baseline Web/WASM validée en 0.3.0, pas de refactorer préventivement le framework.

Le résultat attendu est un Snake exécutable dans le WebView Tauri Android, avec lifecycle, input, assets, logging et provenance cohérents, construit par les toolchains natives prévues sans nouvel orchestrateur Python.

`0.3.1-0-pre.1` — cadrage obligatoire

Avant le développement lourd :

auditer la stable 0.3.0 et ses résultats Web/WASM ;
auditer le POC historique game-reflex-poc-tauri et ses hooks ;
auditer la baseline Android Java/SDL/JNI sans la confondre avec le host Tauri Android ;
identifier les prérequis Tauri Android/SDK/NDK réellement disponibles ;
déterminer ce qui peut être réutilisé tel quel depuis game-snake-poc-wasm et Web/game-snake-poc ;
repérer la duplication réelle avant toute extraction ;
définir les smokes appareil/émulateur et la provenance attendue ;
créer ou réviser le plan 0.3.1 sous docs/plans/ avec découpage prévisionnel souple jusqu'à la stable.

Contraintes gelées

game-snake-poc reste indépendant de Tauri, Android, DOM et providers ;
game-snake-poc-wasm reste l'adapter WASM Snake tant qu'un besoin réel ne justifie pas une extraction ;
ne pas copier le gameplay dans le frontend Tauri ;
ne pas généraliser le frontend Web avant observation du second consommateur ;
si une factorisation Web/WebView devient justifiée, la documenter avec ses deux consommateurs réels ;
ne pas réintroduire scripts/build_reflex_tauri_wasm.py ni créer un nouvel orchestrateur Python pour le chemin touché ;
les builds sont pilotés par Cargo, Tauri CLI, npm/Vite et les toolchains Android natives appropriées ;
ne pas démarrer Tauri Desktop, Android SDL multi-ABI, réseau realtime ou Uroburas dans 0.3.1.

Forecast initial souple

Le forecast doit être confirmé ou corrigé pendant 0-pre.1. Une trajectoire plausible est :

0-pre.1   audit / requirements / sizing / plan
0-pre.2   host Tauri Android Snake minimal + build natif
0-pre.3   lifecycle / input / assets / provenance / logging
0-pre.4   factorisation uniquement si deux consommateurs la justifient
2-beta.1  validation large Android + non-régression Web/Desktop
2-beta.2  consolidation documentaire et transmission
3-rc.1    candidate gelée
0.3.1     release mécanique

Cette numérotation reste révisable conformément aux règles de session.

Validation attendue

Les commandes exactes sont fixées en pre.1 à partir de l'environnement disponible. Au minimum, conserver :

audits statiques du dépôt ;
format/check/Clippy/tests Rust proportionnels ;
build Tauri Android par le chemin natif retenu ;
smoke sur émulateur ou appareil réellement disponible ;
non-régression du host Web Snake 0.3.0 ;
non-régression Desktop SDL3 lorsque la frontière Snake/WASM est touchée.

Condition de fin de session

La session ne s'arrête normalement pas sur une prerelease. Elle doit fermer 0.3.1 jusqu'à la stable ou reporter explicitement le scope non indispensable vers une version suivante si le sizing de pre.1 démontre que la cible est trop grande.

3.8 KiB Raw Blame History