71 lines
3.8 KiB
Markdown
71 lines
3.8 KiB
Markdown
<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# 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 :
|
|
|
|
```text
|
|
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.
|