games/prompts/003-V0_3_1_START_PROMPT.md

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 :

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 :

0.3.1

Première tranche obligatoire :

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 :

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

Puis lire les règles directement pertinentes :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

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 :

(cd <tauri-app> && cargo tauri dev)

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

(cd <tauri-app> && cargo tauri 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 :

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 :

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 :

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 :

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 :

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 :

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 :

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

Pour Tauri, utiliser cargo tauri dev pour les smokes et réserver cargo tauri build aux phases finales de packaging ; 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 :

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 dev) pour les smokes Tauri
(cd <tauri-app> && cargo tauri 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 build) pour le packaging Tauri Android ;
• smoke via (cd <tauri-app> && cargo tauri 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 :

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 :

../builds/sasedev-games/

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

Ne pas livrer :

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 :

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