0.1.0

Android/game-reflex-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 23
+// version: 24
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 1
-        versionName '0.1.0-3-rc.1.fix.1'
+        versionName '0.1.0'
     }
 
     compileOptions {

Android/game-snake-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 23
+// version: 24
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 1
-        versionName '0.1.0-3-rc.1.fix.1'
+        versionName '0.1.0'
     }
 
     compileOptions {

CHANGELOG.md

@@ -1,8 +1,17 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Changelog
 
+## 0.1.0 — 2026-09-17
+
+- validation de `0.1.0-3-rc.1.fix.1` avec gates Rust/audits complètes, builds et smokes Desktop release, Tauri/WASM, Android x86_64/API 36 et Android ARM64 réel ;
+- stabilisation d'une première baseline POC multi-plateforme fondée sur un core de gameplay Rust réutilisé par des runners SDL3 Desktop/Android et un POC Tauri/WebView/WASM ;
+- validation de l'abstraction d'input, du rendu 2D minimal, des assets, de la provenance runtime, du tracing commun et du lifecycle/Back Android ;
+- clôture du cycle POC `0.1.0` sans ajout fonctionnel de dernière minute ;
+- réservation de la direction `0.2.0` : petit kernel moteur, capabilities séparées, adaptateurs plateforme, providers, jeux et services/serveurs composés statiquement ;
+- ajout d'un prompt de conception `0.2.0` afin que l'inventaire détaillé des fonctionnalités et la future architecture soient discutés avant toute implémentation majeure.
+
 ## 0.1.0-3-rc.1 — 2026-09-17
 
 - validation de `2-beta.1.fix.4` sur Desktop SDL3 natif, Tauri/WASM, Android AVD x86_64 et Galaxy S9+ ARM64 ;

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 35
+# version: 36
 
 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.1.0-3-rc.1.fix.1"
+version = "0.1.0"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->
 
 # Roadmap
 
@@ -19,5 +19,9 @@
 - [x] `1-alpha.1` — première API moteur V1 volontairement stabilisée et provenance runtime/input pour les futures sessions et scores.
 - [x] `1-alpha.2` — POC Web/WASM embarqué dans Tauri, sans site distant, et validation de la frontière des services Web/ads.
 - [x] `2-beta.1` — stabilisation, packaging, tests multi-appareils.
-- [ ] `3-rc.1` — candidat de release du socle 0.1.0.
-- [ ] `0.1.0` — première baseline stable du framework POC.
+- [x] `3-rc.1` — candidat de release du socle 0.1.0.
+- [x] `0.1.0` — première baseline stable du framework POC.
+
+## 0.2.0 — Conception du framework modulaire
+
+- [ ] `0.2.0` — inventorier et réserver les capabilities utiles, définir les couches et dépendances autorisées, établir la matrice plateformes et les archétypes de jeux, définir la composition statique et l'architecture cible des crates, puis seulement planifier les implémentations progressives.

crates/apps/game-reflex-poc-tauri/package.json

@@ -1,7 +1,7 @@
 {
   "name": "game-reflex-poc-tauri",
   "private": true,
-  "version": "0.1.0-3-rc.1.fix.1",
+  "version": "0.1.0",
   "type": "module",
   "scripts": {
     "dev": "vite",

crates/apps/game-reflex-poc-tauri/tauri.conf.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "Reflex POC Tauri",
-  "version": "0.1.0-3-rc.1.fix.1",
+  "version": "0.1.0",
   "identifier": "com.sasedev.games.reflex.tauri",
   "build": {
     "beforeDevCommand": {

deltas/0.1.0/rel.md

@@ -0,0 +1,41 @@
+<!-- file: deltas/0.1.0/rel.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0
+
+## Base
+
+Base validée : `0.1.0-3-rc.1.fix.1`.
+
+## Objectif
+
+Promouvoir la RC validée en première baseline stable du framework POC sans introduire de nouvelle fonctionnalité runtime.
+
+## Contenu
+
+- passage des versions workspace, Android et Tauri à `0.1.0` ;
+- clôture de `3-rc.1` et `0.1.0` dans la roadmap ;
+- entrée stable dans le changelog ;
+- enregistrement de la validation RC sous `history/0.1.0/3-rc.1.fix.1.md` ;
+- ajout de `docs/architecture/011-POST_0_1_0_DIRECTION.md` pour conserver les décisions de direction déjà acquises sans figer le design détaillé `0.2.0` ;
+- ajout de `prompts/001-V0_2_0_START_PROMPT.md` pour lancer la phase de brainstorming/conception modulaire.
+
+## Frontière de release
+
+Le catalogue détaillé des capabilities, la matrice plateformes, les dépendances entre couches, le manifest produit/jeu, la future arborescence des crates et la roadmap détaillée `0.2.x` sont volontairement reportés à la phase de conception `0.2.0`.
+
+## Validation
+
+Le delta stable ne modifie aucun fichier Rust ni comportement runtime. Il modifie uniquement les versions de packaging/configuration et la documentation.
+
+Exécuter :
+
+```bash
+cargo fmt --all -- --check
+python3 scripts/audit_rust_workspace_rules.py
+python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates Android deltas history
+python3 scripts/audit_distribution_layout.py
+cargo check --workspace
+```
+
+La suite workspace, Clippy strict et les smokes multi-plateformes ont déjà été validés sur la base RC identique fonctionnellement.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 17 -->
+<!-- version: 18 -->
 
 # Documentation games.sasedev
 
@@ -16,6 +16,7 @@
 - [`architecture/005-ASSET_ARCHITECTURE.md`](architecture/005-ASSET_ARCHITECTURE.md) — assets communs/spécifiques hors crates et packaging.
 - [`architecture/009-ENGINE_V1_RENDER_SCENE.md`](architecture/009-ENGINE_V1_RENDER_SCENE.md) — scène 2D portable, rectangles normalisés et backend SDL3.
 - [`architecture/010-RUNTIME_PROVENANCE.md`](architecture/010-RUNTIME_PROVENANCE.md) — provenance plateforme/device/runtime/input pour sessions, scores et analytics.
+- [`architecture/011-POST_0_1_0_DIRECTION.md`](architecture/011-POST_0_1_0_DIRECTION.md) — décisions de transition entre le POC stable 0.1.0 et la conception modulaire 0.2.0.
 
 ## Jeux
 

docs/architecture/011-POST_0_1_0_DIRECTION.md

@@ -0,0 +1,69 @@
+<!-- file: docs/architecture/011-POST_0_1_0_DIRECTION.md -->
+<!-- version: 1 -->
+
+# Direction après 0.1.0
+
+## Statut
+
+`0.1.0` clôt le POC multi-plateforme.
+
+Cette version démontre qu'un gameplay Rust commun peut être exécuté via SDL3 sur Desktop et Android, ainsi que via WASM dans une application Tauri Desktop. Elle ne constitue pas encore l'architecture définitive du framework.
+
+## Décisions de direction déjà acquises
+
+La génération suivante doit éviter de transformer `engine-v1` en moteur monolithique contenant toutes les fonctionnalités possibles.
+
+La cible conceptuelle sépare au minimum :
+
+- un kernel moteur commun volontairement petit ;
+- des capabilities fonctionnelles réutilisables ;
+- des adaptateurs plateforme ;
+- des providers externes ;
+- les logiques propres aux jeux ;
+- les services et serveurs online ;
+- les outils de build et de distribution.
+
+La composition des produits doit rester statique par défaut. Un jeu ou un launcher ne dépend que des capabilities dont il a réellement besoin et sélectionne explicitement les implémentations disponibles sur sa plateforme.
+
+## Réservation avant implémentation
+
+`0.2.0` commence par une phase de conception.
+
+Elle doit inventorier les besoins plausibles déjà identifiés par les familles de jeux envisagées, les classer et réserver leurs frontières sans créer automatiquement une crate ni une implémentation pour chaque idée.
+
+Une capability réservée n'impose aucune dépendance aux jeux qui ne l'utilisent pas.
+
+Les implémentations sont ensuite ajoutées progressivement lorsqu'un jeu ou un type de jeu en fournit un besoin concret.
+
+## Domaines déjà identifiés pour le brainstorming 0.2.0
+
+Le brainstorming doit notamment couvrir, sans considérer cette liste comme une architecture déjà figée :
+
+- input sémantique, bindings, gestes et contrôles virtuels ;
+- rendu, sprites, textures, animation, maps, tiles et collisions ;
+- score, vies, énergie, expérience, niveaux et progression ;
+- inventaire, équipements, loot, quêtes et systèmes de puzzle réutilisables ;
+- sauvegarde locale, cloud sync et politiques online/offline ;
+- authentification anonyme ou obligatoire et account linking ;
+- leaderboards, achievements, sessions, lobby, matchmaking, chat et multiplayer temps réel ;
+- publicité, rewarded ads, achats intégrés et providers par plateforme ;
+- assets distants, CDN et configuration distante ;
+- logging/tracing par domaines avec politique de build statique ;
+- services Web modulaires et protocoles HTTP, WebSocket, WebRTC ou gRPC selon le besoin ;
+- build/distribution Android multi-ABI sans dépendre durablement du script Python du POC ;
+- comparaison expérimentale SDL Android / Tauri Android ;
+- jeux mono-plateforme autant que jeux multi-plateformes.
+
+## Jeux comme moteurs de validation architecturale
+
+L'architecture future doit être éprouvée par des jeux concrets plutôt que construite dans le vide.
+
+Les POC Reflex et Snake peuvent devenir les premiers laboratoires de modularité : configuration des règles, assets, contrôles, maps, obstacles, multiplayer, parties déterministes et leaderboards.
+
+D'autres archétypes envisagés — aventure/puzzle à énergie et inventaire, course, fighting 1v1, hack'n slash, MMORPG/PKE — servent à révéler des besoins architecturaux, pas à imposer immédiatement leur implémentation.
+
+## Frontière avec 0.1.0
+
+Le catalogue détaillé des capabilities, la matrice plateformes, le graphe de dépendances autorisées, le manifest produit/jeu, l'arborescence cible des crates et la roadmap détaillée des implémentations ne sont volontairement pas figés dans `0.1.0`.
+
+Ils constituent le travail de conception initial de `0.2.0`.

history/0.1.0/3-rc.1.fix.1.md

@@ -0,0 +1,69 @@
+<!-- file: history/0.1.0/3-rc.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.1.0-3-rc.1.fix.1
+
+## Statut
+
+Validé par l'utilisateur le 2026-09-17 puis promu vers `0.1.0`.
+
+## Gate workspace
+
+La gate RC complète a passé :
+
+- `cargo fmt --all` ;
+- `cargo fmt --all -- --check` ;
+- audits Rust, exports, workspace, Markdown et distribution ;
+- `cargo check --workspace` ;
+- `cargo clippy --workspace --all-targets --all-features -- -D warnings` ;
+- `cargo test --workspace --all-targets --all-features`.
+
+Le correctif RC a notamment réaligné le test du bridge JNI sur le contrat `3`.
+
+## Desktop release
+
+Les runners Reflex et Snake ont été construits en `--release`, exécutés, puis arrêtés proprement via SDL3.
+
+## Tauri / WASM
+
+`cargo tauri build` a réussi avec ses hooks de build WASM et Vite/TypeScript.
+
+Le binaire release Tauri a confirmé :
+
+- initialisation du runtime ;
+- tracing frontend ;
+- frontend prêt ;
+- provenance `Desktop / TauriWebView / Wasm / KeyboardMouse`.
+
+## Android x86_64 / API 36
+
+Reflex et Snake ont été reconstruits pour x86_64, assemblés et installés sur l'AVD de référence.
+
+Pour les deux jeux, Back a produit l'observation système puis l'arrêt propre du runtime SDL3 :
+
+```text
+Android system Back observed
+SDL3 runtime stopped
+Finished main function
+```
+
+Aucun `FATAL` ni panic n'a été observé dans ces smokes.
+
+## Android ARM64 réel
+
+Reflex et Snake ont été reconstruits en `arm64-v8a`, assemblés et installés sur le Galaxy S9+ de référence.
+
+Les deux jeux ont démarré avec le tracing Android et le runtime SDL3, puis se sont arrêtés proprement avec la fin de l'Activity SDL.
+
+## Conclusion
+
+La RC couvre les voies de distribution et d'exécution du POC :
+
+```text
+Desktop SDL3 natif
+Tauri / WebView / WASM
+Android x86_64 / API 36
+Android ARM64 réel
+```
+
+Aucun changement fonctionnel supplémentaire n'est requis pour la promotion `0.1.0`.

prompts/001-V0_2_0_START_PROMPT.md

@@ -0,0 +1,84 @@
+<!-- file: prompts/001-V0_2_0_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.2.0 — conception du framework modulaire
+
+Partir de la version stable `0.1.0` et considérer cette version comme la clôture du POC multi-plateforme. Lire intégralement `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/000-README.md`, `docs/architecture/011-POST_0_1_0_DIRECTION.md`, les documents d'architecture existants, `history/0.1.0/3-rc.1.fix.1.md` et `deltas/0.1.0/rel.md` avant toute proposition.
+
+La première phase `0.2.0` est une phase de conception et de réservation architecturale. Ne pas commencer par développer massivement de nouvelles fonctionnalités ni par créer une crate pour chaque idée.
+
+## Objectif
+
+Transformer le POC en architecture de framework modulaire capable d'accueillir progressivement des jeux très différents tout en gardant un kernel moteur réduit et des dépendances explicites.
+
+Les fonctionnalités doivent être inventoriées et réservées lorsqu'un besoin plausible concret est déjà identifiable, puis implémentées seulement lorsqu'un jeu, un archétype ou une plateforme les exige réellement.
+
+## Travail de conception obligatoire
+
+Effectuer les étapes suivantes dans cet ordre, avec discussion/audit avant gel :
+
+1. établir un inventaire large des capabilities plausibles déjà justifiées par les jeux et plateformes envisagés ;
+2. classer chaque élément dans une couche explicite : `kernel`, `capability`, `platform adapter`, `provider`, `game/system`, `server/service` ou `tooling` ;
+3. définir les dépendances autorisées et interdites entre ces couches ;
+4. définir une matrice des capacités par plateforme : Desktop SDL, Android SDL, Web/WASM, Tauri Desktop et Tauri Android expérimental ;
+5. définir les archétypes de jeux et leurs besoins : reflex/arcade, snake/grid, puzzle/adventure, racing, fighting 1v1, hack'n slash, multiplayer compétitif, MMORPG/PKE et autres besoins déjà identifiés ;
+6. distinguer capability générique, système de jeu réutilisable et logique spécifique à un jeu ;
+7. définir le modèle de composition statique des produits et éviter de faire reposer toute la composition sur des Cargo features globales ;
+8. concevoir un manifest machine-readable de produit/jeu décrivant capabilities requises, optionnelles, non supportées, dépendantes d'un serveur ou spécifiques à une plateforme ;
+9. définir l'architecture cible des crates sans créer immédiatement toutes les crates réservées ;
+10. définir la stratégie de logging/tracing par domaines de crates et la configuration statique de build par produit/plateforme ;
+11. définir les frontières auth/identity, online/offline, persistence/sync, ads/providers, leaderboards, multiplayer, assets/CDN et services Web ;
+12. étudier explicitement le POC Tauri Android en comparaison de SDL Android ;
+13. remplacer à terme l'orchestration Android Python du POC par un outil/build system multi-ABI conçu pour le projet ;
+14. seulement après validation de cette conception, proposer la roadmap détaillée `0.2.x`, puis les orientations `0.3.x` et suivantes.
+
+## Exemples de pression architecturale
+
+Utiliser des jeux concrets pour tester la conception, sans les implémenter tous immédiatement.
+
+### Snake
+
+Prévoir notamment la possibilité de configurer taille de grille et serpent, croissance, vitesse, textures tête/corps/queue, obstacles, murs ou wrap, collisions avec soi/autres serpents, plusieurs joueurs locaux/IA/online, variantes de maps et leaderboard.
+
+### Reflex
+
+Prévoir des parties déterministes ou générées, mêmes séquences pour plusieurs joueurs, taille/skin/durée des cibles, scoring, comparaison de scores, validation serveur et leaderboard.
+
+### Adventure/puzzle à énergie
+
+Considérer énergie, inventaire, progression/XP/niveaux, maps/tiles, Sokoban, pipes, lasers/mirrors, rewarded ads, événements et classement.
+
+### Racing / fighting / hack'n slash / MMORPG-PKE
+
+Utiliser ces familles pour challenger input, temps réel, authoritative server, sessions/lobby/matchmaking, synchronisation, chat, persistence, économie et éventuelles rewards externes, sans intégrer ces domaines dans le kernel moteur.
+
+## Livrables de conception attendus
+
+Créer au minimum, sous réserve de validation des noms pendant la session :
+
+```text
+docs/architecture/CAPABILITY_CATALOG.md
+docs/architecture/LAYERING_AND_DEPENDENCIES.md
+docs/architecture/PLATFORM_CAPABILITY_MATRIX.md
+docs/games/GAME_ARCHETYPES_AND_REQUIREMENTS.md
+```
+
+Le catalogue doit pouvoir attribuer à une capability un statut tel que `Reserved`, `Planned`, `Experimental`, `Implemented`, `PlatformSpecific`, `Unsupported(platform)` ou `Deprecated` sans que la simple réservation déclenche une implémentation.
+
+## Contraintes
+
+- ne pas transformer `engine-v1` en moteur monolithique ;
+- conserver le gameplay portable indépendant des APIs de providers et plateformes ;
+- préférer des contrats explicites et des adaptateurs aux `#[cfg]` dispersés dans les jeux ;
+- ne pas charger dynamiquement des bibliothèques sans besoin démontré ;
+- garder la composition statique Rust comme défaut ;
+- ne pas figer prématurément une API ou une crate pour une fonctionnalité purement spéculative ;
+- distinguer disponibilité, désactivation volontaire et non-support d'une capability ;
+- permettre qu'un jeu soit mono-plateforme, multi-plateforme, offline-only, online-optional ou online-required ;
+- respecter toutes les règles de version, audit, tests, fichiers et livraisons du dépôt.
+
+## Résultat attendu de la première session 0.2.0
+
+La session doit d'abord produire une architecture documentée cohérente et une roadmap d'implémentation progressive.
+
+Le développement fonctionnel significatif ne commence qu'après validation de cette conception.