<!-- file: prompts/003-V0_3_1_START_PROMPT.md -->
<!-- version: 4 -->

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

## 1. Base exacte et autorité de la reprise

Partir uniquement de la version stable/taggée :

```text
v0.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 puis la release stable `0.3.0`.

Lorsqu'une archive est fournie comme téléchargement du tag `v0.3.0`, elle constitue la baseline autoritaire même si elle ne contient pas `.git`. Appliquer `CMD-GIT-003` et `CMD-GIT-004` : vérifier la cohérence interne des versions et des fichiers, ne pas inventer un état Git inaccessible.

Version cible :

```text
0.3.1
```

Première tranche obligatoire :

```text
0.3.1-0-pre.1
```

`0-pre.1` est un gate de lecture, audit, requirements, sizing, validation et planification. Ne pas commencer directement par le scaffold Android/Tauri ou par la copie du POC Reflex.

## 2. Sources de vérité — ordre de lecture obligatoire

Lire intégralement, dans cet ordre :

```text
RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
```

Puis lire les règles directement pertinentes :

```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
```

Le prompt résume les garde-fous nécessaires à `0.3.1`; les règles restent normatives en cas de détail absent ici.

Lire ensuite la transmission `0.3.0` :

```text
docs/plans/001-V0_3_0_WEB_SNAKE_POC_PLAN.md
docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md
docs/architecture/018-V0_3_0_WEB_SNAKE_BASELINE.md
docs/testing/004-V0_3_0_RC_VALIDATION_MATRIX.md
history/0.3.0/
deltas/0.3.0/
```

Enfin auditer les implémentations réellement concernées :

```text
crates/games/game-snake-poc/
crates/apps/game-snake-poc-wasm/
Web/game-snake-poc/
crates/apps/game-snake-poc-desktop/
crates/apps/game-reflex-poc-tauri/
crates/apps/game-reflex-poc-wasm/
Android/
assets/
```

Ne pas déduire l'état d'une crate depuis ce prompt lorsque le code stable `0.3.0` dit autre chose.

## 3. État hérité attendu de `0.3.0`

La stable `0.3.0` doit avoir validé au minimum :

```text
Snake gameplay indépendant des hosts
runner Desktop SDL3 fonctionnel
adapter Snake WASM dédié
host navigateur direct Vite/TypeScript
shell HTML Bootstrap 5 / Bootswatch / SimpleBar
Canvas respectant le ratio logique Snake
clavier + contrôles pointer/tactiles
lifecycle navigateur fixed-step sans catch-up massif
assets common/game packagés depuis assets/
logging frontend structuré
RuntimeProvenance Web / Browser / Wasm
build WASM release + wasm-bindgen
build Vite production + preview
```

Cette liste est un handoff attendu, pas une validation à réexécuter aveuglément au premier instant. Confirmer l'état réel de la stable puis définir les non-régressions nécessaires à `0.3.1`.

## 4. Mission de `0.3.1`

`0.3.1` doit produire le second host Snake : Tauri Android.

Le but est de vérifier que la baseline Web/WASM de `0.3.0` peut être réutilisée dans un WebView mobile Tauri sans recopier le gameplay, sans dupliquer inutilement le bridge WASM et sans créer un framework abstrait avant preuve d'un besoin partagé.

Résultat attendu :

```text
Snake exécutable dans un host Tauri Android
build Android piloté par les outils Tauri/Android natifs retenus
lifecycle mobile cohérent
input tactile et comportement WebView cohérents
assets accessibles dans le package final
logging Rust/Tauri/frontend cohérent
RuntimeProvenance distincte du navigateur direct
non-régression du host Web direct 0.3.0
non-régression Desktop SDL3 si une frontière partagée change
```

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

Avant tout développement lourd, produire un audit réel de la stable `0.3.0` et de l'environnement disponible.

### 5.1 Baseline Snake

Auditer :

```text
game-snake-poc
game-snake-poc-wasm
Web/game-snake-poc
game-snake-poc-desktop
engine-v1-common
engine-v1-platform-api
assets communs et Snake
```

Identifier explicitement :

- ce qui est réutilisable tel quel ;
- ce qui est spécifique au navigateur direct ;
- ce qui appartient déjà à l'adapter WASM ;
- ce qui deviendrait réellement partagé entre navigateur et WebView Tauri ;
- toute duplication prouvée avant extraction.

### 5.2 Référence Tauri existante

Auditer intégralement :

```text
crates/apps/game-reflex-poc-tauri/
crates/apps/game-reflex-poc-wasm/
docs/development/008-WASM_TAURI_POC.md
```

Le POC Reflex est une référence technique de structure, de bridge Tauri, de frontend et de logging. Il n'est pas un template à copier aveuglément si sa baseline historique contredit les règles `0.3.x`.

Vérifier notamment :

```text
src/lib.rs comme façade/reexports
src/tauri.rs comme assemblage Tauri et pont Web/Rust
modules propriétaires séparés
tauri.conf.json / capabilities / permissions
hooks frontend Vite
tauri-plugin-tracing / @fltsci/tauri-plugin-tracing
organisation frontend HTML/Sass/TypeScript
```

### 5.3 Android existant

Auditer `Android/` et les documents Android existants pour distinguer :

```text
baseline Android SDL3/Java/JNI
host Tauri Android de 0.3.1
```

Ils peuvent partager des contraintes plateforme, SDK/NDK ou documentation, mais ne doivent pas être confondus ni couplés artificiellement.

### 5.4 Toolchains réelles

Inventorier ce qui est réellement disponible dans l'environnement utilisateur :

```text
Rust targets Android nécessaires
Tauri CLI/version réellement utilisée
Android SDK
Android NDK
Java/JDK
Gradle/tooling éventuellement piloté par Tauri
adb
émulateur/AVD éventuel
appareil réel éventuel
Node/npm
```

Ne pas déclarer un smoke appareil/émulateur possible avant de confirmer qu'une cible est effectivement accessible.

### 5.5 Sizing et plan

Créer ou réviser obligatoirement le plan de `0.3.1` sous :

```text
docs/plans/
```

Le plan doit contenir :

- objectif et scope ;
- décisions acquises ;
- risques/dépendances utiles ;
- hors-périmètre ;
- validations prévues ;
- découpage prévisionnel souple jusqu'à `0.3.1` stable ;
- tranche de validation large ;
- tranche de consolidation documentaire ;
- RC gelée ;
- release stable mécanique.

Si le sizing montre que Tauri Android complet ne tient pas raisonnablement dans une session, réduire ou scinder le scope avant l'implémentation lourde.

## 6. Contraintes architecturales gelées

Préserver les frontières suivantes :

```text
game-snake-poc
    gameplay et règles de jeu

engine-v1-common
    contrats moteur portables

engine-v1-platform-api
    provenance/capabilities plateforme

game-snake-poc-wasm
    adaptation WASM Snake

host Web direct / host Tauri
    lifecycle, DOM/WebView, inputs physiques, packaging et UI
```

Règles spécifiques :

- `game-snake-poc` reste indépendant de Tauri, Android, DOM, Canvas et providers ;
- ne pas copier le gameplay dans TypeScript, Java ou le backend Tauri ;
- conserver `game-snake-poc-wasm` comme adapter WASM tant qu'un besoin réel ne justifie pas une extraction ;
- ne pas généraliser `Web/game-snake-poc` avant observation du second consommateur ;
- une extraction commune Web/WebView n'est autorisée que si deux consommateurs réels prouvent sa valeur ;
- `lib.rs` d'une app Tauri reste une façade/reexport ;
- `tauri.rs` assemble Tauri et délègue aux modules propriétaires ;
- les traces frontend Tauri utilisent le bridge tracing prévu par les règles, pas des `console.*` applicatifs dispersés ;
- ne pas réintroduire d'orchestrateur Python de build ;
- ne pas utiliser `scripts/build_reflex_tauri_wasm.py` pour le nouveau chemin `0.3.x` ;
- ne pas introduire réseau realtime, Uroburas, ads, billing ou leaderboard dans `0.3.1`.

## 7. Frontend Tauri et commandes Web

Le frontend Tauri peut reprendre les conventions de shell déjà éprouvées dans les applications Desk KSP et dans le POC existant lorsque cela reste pertinent :

```text
Vite
TypeScript
HTML/Sass
Bootstrap 5 / thème retenu
Font Awesome
SimpleBar + ResizeObserver si le layout le nécessite
```

Pour une application Tauri, `npm` sert seulement à gérer les dépendances frontend lorsqu'une dépendance doit être ajoutée/retirée (`npm i`, `npm i -D`, etc.). Ne pas utiliser `npm run dev` ou `npm run build` comme gates Tauri manuelles : les hooks Tauri possèdent Vite/TypeScript/WASM.

Le smoke courant utilise :

```bash
(cd <tauri-app> && cargo tauri android dev)
```

Le packaging est réservé aux phases finales prévues par le plan :

```bash
(cd <tauri-app> && cargo tauri android build)
```

Ne pas traiter le host Tauri comme le host navigateur direct de `0.3.0` : le mode de lancement, le packaging, les permissions et les smokes sont différents.

## 8. Provenance attendue

Le host Tauri Android doit produire une provenance distincte du navigateur direct.

`0-pre.1` doit auditer les enums/contrats réels de `engine-v1-platform-api` avant de fixer les valeurs exactes, mais préserver les dimensions :

```text
platform family
runtime host
execution model
device class
input profile
```

Ne pas ajouter une identification matérielle fine uniquement pour ce POC.

## 9. Documentation des crates/packages

Pendant `0-pre.1`, appliquer `DOC-CRATE-*` à tout composant créé ou finalisé.

La question doit être explicitement tranchée pour la nouvelle app Tauri :

```text
README.md ?
    responsabilité / frontières / architecture locale / points d'entrée

USAGE.md ?
    prérequis / commandes / installation / lancement / smoke opérateur
```

Ne pas créer des fichiers vides ou redondants. Si la documentation centrale couvre réellement un petit adapter, le plan peut documenter pourquoi un fichier local séparé n'apporte rien.

Lors de la consolidation finale, refaire cette revue pour chaque crate/package considéré durable dans `0.3.1`.

## 10. Deltas, history et état validé

Ne pas confondre :

```text
deltas/<X.Y.Z>/
    décrit la livraison candidate
    base requise
    fichiers ajoutés/modifiés/supprimés
    décisions
    validations à exécuter
    validations non exécutées

history/<X.Y.Z>/
    décrit un jalon effectivement validé
    résultats réellement fournis par l'utilisateur
    défauts acceptés/corrigés
    état transmis au jalon suivant
```

Une entrée `history/` n'est jamais pré-écrite pour le delta courant. Après validation utilisateur, le delta suivant ou son fix crée l'entrée historique du jalon accepté conformément à `DOC-HIST-*`.

Les anciens fichiers de `deltas/` et `history/` restent immuables sur le fond.

## 11. CHANGELOG, ROADMAP, plan et prompt suivant

Appliquer ces responsabilités sans les mélanger :

### Plan

`docs/plans/` porte le suivi fin et vivant de `0.3.1`. Il est créé/révisé en `0-pre.1` puis réconcilié lorsqu'un résultat réel modifie la trajectoire.

### ROADMAP

`ROADMAP.md` reste macroscopique. Le modifier lorsqu'un scope est ajouté, réalisé, reporté ou annulé ; ne pas ajouter une ligne pour chaque prerelease/fix.

### CHANGELOG

`CHANGELOG.md` est une synthèse de publication. Les `pre`, `alpha`, `beta` et fixes ne créent normalement pas d'entrée. Écrire la synthèse candidate à partir de la RC, puis la synthèse stable lors de la release.

### Prompt de la version suivante

Rédiger le prompt suivant pendant la consolidation finale de `0.3.1` lorsque la cible `0.3.2` est suffisamment connue. La première RC gelée vérifie/complète le prompt à partir de l'état réellement candidat à publication.

Ne jamais présenter dans ce prompt futur une validation RC/stable qui n'a pas encore été exécutée.

## 12. Commandes et matrice de validation

Ne pas inventer une procédure de commandes parallèle dans le prompt.

Sources normatives :

```text
docs/rules/RULES_COMMANDS.md
docs/rules/RULES_VALIDATION_MATRIX.md
```

`RULES_COMMANDS.md` définit quand utiliser les audits, Cargo, Web, Android, Tauri et les smokes.

`RULES_VALIDATION_MATRIX.md` définit les IDs `CMD-*`, leurs dépendances et leurs déclencheurs.

Chaque delta sélectionne les commandes proportionnelles à son scope. Une commande non exécutée n'est jamais déclarée PASS.

Les audits Python sont choisis selon les fichiers touchés : ne pas exécuter systématiquement les trois audits si un seul est pertinent.

Dès qu'un delta touche du code Rust, un manifeste Cargo, une feature ou une dépendance Rust, la base obligatoire est :

```bash
cargo fmt --all
cargo fmt --all -- --check
# audits Python applicables au scope
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
```

Les tests normaux sont ciblés :

```bash
cargo test -p <crate> --all-targets --all-features
```

Ajouter les tests ciblés des consommateurs uniquement lorsque leur contrat est affecté. `cargo test --workspace --all-targets --all-features` reste une gate rare, planifiée un petit nombre de fois dans la version/session (initiale si utile, préfinale/finale, ou portée transverse incertaine).

Ne lancer `cargo tree` que si les dépendances/features changent ou qu'un diagnostic de frontière le justifie. Ne pas le mettre automatiquement dans chaque log de validation.

Toute commande nécessitant un changement de répertoire est englobée dans un sous-shell :

```bash
(cd <répertoire> && <commande>)
```

Pour Tauri, utiliser `cargo tauri android dev` pour les smokes Android et réserver `cargo tauri android build` aux phases finales de packaging Android ; `npm` n'est utilisé directement que pour gérer les dépendances frontend.

## 13. Qui exécute quoi

Le générateur peut exécuter les audits statiques en lecture seule afin de préparer un delta.

Les validations de build/runtime restent côté utilisateur :

```text
cargo check workspace + Clippy workspace strict lorsqu'un delta touche Rust/dépendances
tests cargo ciblés par défaut
test workspace complet seulement aux jalons planifiés/portées incertaines
(cd <tauri-app> && cargo tauri android dev) pour les smokes Tauri
(cd <tauri-app> && cargo tauri android build) pour les validations finales de packaging Tauri
Gradle/SDK/NDK lorsque le chemin Tauri les invoque
installation émulateur/appareil
smoke mobile
smoke Web direct de non-régression
smoke Desktop SDL3 si requis
```

Ne jamais annoncer un build ou un smoke comme réussi uniquement parce que le code paraît correct.

Une gate utilisateur propre permet de passer automatiquement à la tranche planifiée suivante sauf instruction contraire. Une gate en échec reste normalement dans un `.fix.N` de la tranche courante.

## 14. Forecast initial souple

Le forecast suivant est une hypothèse à confirmer ou corriger en `0-pre.1`.

### `0-pre.1` — audit / requirements / sizing / plan

- audit stable `0.3.0` ;
- audit Reflex Tauri/WASM ;
- audit environnement Tauri Android ;
- matrice réutilisation vs duplication ;
- stratégie de build/smoke ;
- positionnement explicite des rares gates `cargo test --workspace --all-targets --all-features` dans le plan ;
- plan `0.3.1` ;
- décision README/USAGE attendue pour les nouveaux composants.

### `0-pre.2` — host Tauri Android Snake minimal

- nouvelle app Tauri Android au bon emplacement ;
- consommation de l'adapter WASM Snake existant ou adaptation minimale justifiée ;
- premier build natif reproductible ;
- aucune généralisation prématurée.

### `0-pre.3` — lifecycle / input / assets / provenance / logging

- lifecycle WebView/mobile ;
- tactile/input ;
- assets ;
- provenance ;
- tracing Rust/Tauri/frontend ;
- erreurs de runtime visibles et sûres.

### `0-pre.4` — extraction conditionnelle

Créer uniquement si le second host révèle une duplication partagée réelle entre navigateur direct et Tauri WebView.

Sinon omettre la tranche.

### `2-beta.1` — validation large

- workspace complet ;
- `(cd <tauri-app> && cargo tauri android build)` pour le packaging Tauri Android ;
- smoke via `(cd <tauri-app> && cargo tauri android dev)` puis émulateur/appareil disponible ;
- non-régression Web direct ;
- non-régression Desktop SDL3 lorsque nécessaire ;
- vérification dépendances/package/distribution.

### `2-beta.2` — consolidation documentaire

- documentation durable ;
- README/USAGE réellement nécessaires ;
- plan réconcilié ;
- history ;
- ROADMAP selon le scope réellement livré ;
- préparation du prompt `0.3.2` ;
- matière de CHANGELOG prête sans créer une entrée beta artificielle.

### `3-rc.1` — candidate gelée

- scope fonctionnel gelé ;
- entrée RC du `CHANGELOG.md` ;
- matrice RC ;
- reproductibilité packaging ;
- prompt `0.3.2` vérifié/complété ;
- seulement bugs/release blockers ensuite.

### `0.3.1` — stable

Release mécanique de la RC validée : versions finales, synthèse stable, delta/release et tag selon le workflow applicable.

La numérotation est révisable. Les responsabilités ne doivent pas être fusionnées uniquement pour raccourcir artificiellement la version.

## 15. Hors-périmètre explicite

Ne pas ouvrir dans `0.3.1` sans décision de replanification :

```text
Tauri Desktop Snake comme nouveau produit
refonte générale engine-v1
engine-v2
Android SDL3 multi-ABI supplémentaire
nouveau framework frontend générique
serveur realtime
WebSocket/WebTransport/QUIC gameplay
Uroburas
ads/billing
leaderboard/auth
refactor massif de Reflex
mise à niveau opportuniste des dépendances
```

Une dépendance peut être mise à jour uniquement si elle est nécessaire au chemin `0.3.1` et que le delta le documente.

## 16. Packaging et fichiers générés

Respecter :

```text
../builds/sasedev-games/
```

pour les sorties Cargo/Tauri/Vite et caches concernés.

Ne pas livrer :

```text
node_modules/
dist/
target/
bindings wasm générés
caches
secrets
lockfiles interdits par les règles du dépôt
```

Le ZIP d'un delta contient uniquement les fichiers ajoutés/modifiés par la tranche plus son document de delta, et les suppressions éventuelles utilisent le manifest contractuel prévu.

## 17. Première séquence de travail de la session

À l'ouverture de `0.3.1` :

1. vérifier que la base fournie correspond réellement à la stable `0.3.0` ;
2. lire les sources de vérité dans l'ordre indiqué ;
3. lire le dernier `history/0.3.0` et le delta/release stable ;
4. exécuter les audits statiques applicables à la baseline ;
5. auditer `game-reflex-poc-tauri` et le chemin Tauri Android disponible ;
6. auditer `game-snake-poc-wasm` et le host Web direct ;
7. inventorier SDK/NDK/Tauri/adb/AVD/appareil réellement accessibles ;
8. produire requirements, risques, hors-périmètre et sizing ;
9. créer le plan `0.3.1` sous `docs/plans/` ;
10. seulement ensuite ouvrir le premier delta de développement.

## 18. Condition de fin de session

La session est dimensionnée pour fermer `0.3.1` jusqu'à sa stable.

Une prerelease n'est pas une cible normale de fin de session. Si le sizing ou une contrainte externe rend l'objectif trop grand, reporter explicitement le scope non indispensable vers `0.3.2+` plutôt que prolonger indéfiniment `0.3.1`.

La stable doit arriver avec :

```text
scope validé
builds/smokes applicables validés
documentation durable réconciliée
history complet des jalons acceptés
ROADMAP cohérente
CHANGELOG RC/stable cohérent
prompt de la version suivante prêt et vérifié
delta/release mécanique sans nouveau scope
```