0.2.0-0-pre.4

2026-09-18 15:03:33 +02:00
parent 2a0cf4dd2b
commit a8ab312a3a
11 changed files with 545 additions and 9 deletions
--- a/Android/game-reflex-poc/build.gradle
+++ b/Android/game-reflex-poc/build.gradle
@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 33
+// version: 34

 plugins {
    id 'com.android.application'
@@ -18,7 +18,7 @@ android {
        minSdk 21
        targetSdk 36
        versionCode 2
-        versionName '0.2.0-0-pre.3.fix.1'
+        versionName '0.2.0-0-pre.4'
    }

    compileOptions {
--- a/Android/game-snake-poc/build.gradle
+++ b/Android/game-snake-poc/build.gradle
@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 33
+// version: 34

 plugins {
    id 'com.android.application'
@@ -18,7 +18,7 @@ android {
        minSdk 21
        targetSdk 36
        versionCode 2
-        versionName '0.2.0-0-pre.3.fix.1'
+        versionName '0.2.0-0-pre.4'
    }

    compileOptions {
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 45
+# version: 46

 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]

 [workspace.package]
-version = "0.2.0-0-pre.3.fix.1"
+version = "0.2.0-0-pre.4"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->

 # games.sasedev

@@ -25,7 +25,7 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale

 Version stable de référence : `0.1.0`.

-Version candidate en cours de conception : `0.2.0-0-pre.3.fix.1`.
+Version candidate en cours de conception : `0.2.0-0-pre.4`.

 Les deux premiers jeux sont des POC structurels : `game-reflex-poc` et `game-snake-poc`. Ils existent d'abord pour valider les frontières du workspace, le moteur, les assets et le packaging multiplateforme.

--- a/deltas/0.2.0/0-pre.4.md
+++ b/deltas/0.2.0/0-pre.4.md
@@ -0,0 +1,55 @@
+<!-- file: deltas/0.2.0/0-pre.4.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.4
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.3.fix.1`.
+
+## Objet
+
+Définir les POC plateforme utiles avant toute implémentation de la série suivante.
+
+## Études ajoutées
+
+- candidats POC plateforme ;
+- réutilisation du code existant ;
+- matrice commune de validation ;
+- séquence proposée pour une future série `0.3.x`.
+
+## POC prioritaires étudiés
+
+Première vague candidate :
+
+- Tauri Android + Reflex ;
+- Web navigateur direct + Reflex ;
+- Tauri Desktop + Snake ;
+- builder Android multi-ABI.
+
+Deuxième vague lorsque l'environnement existe :
+
+- Windows SDL natif ;
+- macOS SDL natif ;
+- iOS SDL natif.
+
+Tauri iOS reste conditionnel aux résultats Tauri Android et à l'existence d'un besoin Apple réel.
+
+## Principes
+
+- réutiliser le gameplay existant ;
+- minimiser le code spécifique ;
+- mesurer la duplication ;
+- ne pas extraire prématurément une abstraction avant d'avoir observé au moins un besoin réel ;
+- comparer SDL natif, Web/WASM et Tauri/WebView ;
+- ne pas implémenter les POC dans `0.2.0`.
+
+## Validation
+
+```bash
+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
+```
+
+Aucune gate Cargo/Gradle/smoke n'est requise pour ce delta documentaire.
--- a/docs/studies/000-README.md
+++ b/docs/studies/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->

 # Études

@@ -28,3 +28,12 @@ Les études conservent les alternatives et raisons utiles à la compréhension f
 - [`008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md`](008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md) — identité canonique, providers externes, hébergement global puis sites/services propres à chaque jeu.

 Ces études sont des propositions à relire. Elles ne deviennent pas automatiquement des décisions d'architecture.
+
+## Études POC plateforme
+
+- [`009-PLATFORM_POC_CANDIDATES.md`](009-PLATFORM_POC_CANDIDATES.md) — inventaire des POC réellement pertinents à partir du code existant.
+- [`010-PLATFORM_POC_REUSE_AND_DELTA.md`](010-PLATFORM_POC_REUSE_AND_DELTA.md) — code réutilisable, modifications minimales et frontières à tester.
+- [`011-PLATFORM_POC_VALIDATION_MATRIX.md`](011-PLATFORM_POC_VALIDATION_MATRIX.md) — critères comparables de build, runtime, input, packaging et intégration plateforme.
+- [`012-PLATFORM_POC_SEQUENCE.md`](012-PLATFORM_POC_SEQUENCE.md) — ordre proposé des POC pour une future série `0.3.x`.
+
+Ces documents étudient les POC à réaliser ; ils ne lancent encore aucune implémentation.
--- a/docs/studies/009-PLATFORM_POC_CANDIDATES.md
+++ b/docs/studies/009-PLATFORM_POC_CANDIDATES.md
@@ -0,0 +1,231 @@
+<!-- file: docs/studies/009-PLATFORM_POC_CANDIDATES.md -->
+<!-- version: 1 -->
+
+# Candidats POC plateforme
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.4`.
+
+## Objectif
+
+Identifier les POC plateforme qui apportent une information architecturale réelle en réutilisant au maximum le code déjà validé en `0.1.0`.
+
+Le but n'est pas de multiplier les variantes pour leur propre intérêt.
+
+## Baseline déjà disponible
+
+Le projet dispose déjà de :
+
+- Reflex Rust réutilisable ;
+- Snake Rust réutilisable ;
+- runner SDL3 Desktop ;
+- Android SDL3 + Java/JNI ;
+- Tauri Desktop + Vite/TypeScript + WASM pour Reflex ;
+- provenance runtime ;
+- tracing commun ;
+- abstraction initiale d'input ;
+- politique de build externe ;
+- validation Android x86_64 et ARM64.
+
+Les POC futurs doivent partir de cette base.
+
+## POC A — Tauri Android avec Reflex
+
+### Question
+
+Le chemin Tauri Android peut-il exécuter le même gameplay Reflex déjà utilisé par Tauri Desktop/WASM avec une intégration mobile acceptable ?
+
+### Réutilisation visée
+
+- `game-reflex-poc` ;
+- `game-reflex-poc-wasm` si le modèle reste Wasm/WebView ;
+- frontend Vite/TypeScript existant ;
+- tracing frontend/Tauri ;
+- assets existants ;
+- provenance runtime étendue.
+
+### Modifications attendues
+
+- génération/projet mobile Tauri ;
+- input tactile ;
+- lifecycle Android ;
+- orientation/fullscreen ;
+- packaging APK/AAB ;
+- ABI ;
+- logging Android/Tauri ;
+- éventuels plugins mobiles.
+
+### Ce que le POC doit apprendre
+
+- complexité réelle du build ;
+- taille binaire/package ;
+- startup ;
+- latence input ;
+- stabilité lifecycle ;
+- accès aux APIs/plugins natifs ;
+- faisabilité ads/auth plus tard ;
+- coût de maintenance par rapport au chemin SDL Android.
+
+## POC B — Web navigateur direct avec Reflex
+
+### Question
+
+Le même gameplay WASM peut-il être livré comme jeu Web direct, sans Tauri, avec un packaging propre et un input navigateur fiable ?
+
+### Réutilisation visée
+
+- `game-reflex-poc` ;
+- crate WASM existante ;
+- Vite/TypeScript partagé autant que pertinent ;
+- assets communs.
+
+### Points à tester
+
+- browser host ;
+- resize ;
+- pointer/touch ;
+- fullscreen ;
+- focus/visibility ;
+- persistence navigateur minimale ;
+- build statique ;
+- chargement assets ;
+- tracing console ;
+- hébergement sous un chemin non racine.
+
+## POC C — Tauri Desktop avec Snake
+
+### Question
+
+La voie Tauri/WASM validée avec Reflex est-elle réellement générique ou trop spécifique au premier POC ?
+
+### Pourquoi Snake
+
+Snake exerce :
+
+- keyboard input continu ;
+- cadence update différente ;
+- état plus long ;
+- rendu d'entités multiples ;
+- logique de quit/pause différente.
+
+### Réutilisation visée
+
+Créer le minimum nécessaire pour que Snake utilise les mêmes contrats Tauri/WASM que Reflex.
+
+Si cela exige de copier beaucoup de code frontend/bridge, cela signale une capability ou un adapter à extraire.
+
+## POC D — Windows SDL natif
+
+### Question
+
+Le runner SDL3 natif et le workspace Rust se construisent-ils proprement sur Windows avec une divergence minimale ?
+
+### Périmètre
+
+Reflex ou Snake, selon la cible la plus simple.
+
+### À tester
+
+- toolchain Rust MSVC ;
+- SDL3 ;
+- assets ;
+- input ;
+- audio si disponible ;
+- packaging minimal ;
+- logs ;
+- chemins/filesystem.
+
+Ce POC nécessite une machine ou CI Windows réelle ; le cross-build Linux ne remplace pas un smoke Windows.
+
+## POC E — macOS SDL natif
+
+### Question
+
+Le backend SDL natif actuel peut-il devenir une cible macOS sans modification du gameplay ?
+
+SDL3 documente macOS comme plateforme supportée.
+
+### À tester ultérieurement
+
+- build x86_64/arm64 selon environnement ;
+- SDL3 framework/dylib ;
+- app bundle ;
+- input ;
+- filesystem ;
+- signing/notarization seulement dans une phase de distribution ultérieure.
+
+Nécessite un environnement macOS réel pour être validé.
+
+## POC F — iOS SDL natif
+
+### Question
+
+Le modèle Android/SDL peut-il être adapté à iOS tout en conservant le même gameplay ?
+
+SDL3 documente iOS et son usage via `SDL3.xcframework`.
+
+### Périmètre futur
+
+- build iOS ;
+- simulator/device ;
+- lifecycle ;
+- touch ;
+- app storage ;
+- packaging Xcode.
+
+Ce POC est réservé à une phase disposant de macOS/Xcode et ne doit pas bloquer les POC immédiatement réalisables sous Linux/Android.
+
+## POC G — Tauri iOS
+
+Candidat plus lointain.
+
+Il n'est utile qu'après :
+
+- validation du POC Tauri Android ;
+- disponibilité d'un environnement Apple ;
+- intérêt réel pour comparer deux chemins mobiles Apple.
+
+Il ne doit pas être planifié par défaut dans la première vague.
+
+## POC H — builder Android multi-ABI
+
+### Question
+
+Peut-on remplacer les scripts Python POC par un outil de build explicite, reproductible et commun aux jeux ?
+
+### Périmètre
+
+- `arm64-v8a` ;
+- `x86_64` ;
+- éventuellement autres ABI seulement si réellement supportées ;
+- Debug/Release ;
+- Reflex/Snake ;
+- placement contrôlé des artefacts ;
+- Gradle orchestration ;
+- diagnostic clair des prérequis.
+
+Ce POC est plutôt un POC tooling qu'un POC runtime.
+
+## Candidats non prioritaires
+
+Ne pas lancer immédiatement :
+
+- Tauri iOS ;
+- macOS Tauri spécifique si Tauri Desktop actuel suffit déjà à tester le host ;
+- Linux SDL supplémentaire, déjà baseline ;
+- nouvelle technologie de rendu ;
+- nouveau moteur Web ;
+- nouvelles plateformes console.
+
+## Résultat attendu
+
+La première vague doit surtout comparer trois chemins :
+
+```text
+SDL native
+Web/WASM
+Tauri/WebView
+```
+
+sur plusieurs hosts sans modifier le gameplay.
--- a/docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md
+++ b/docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md
@@ -0,0 +1,97 @@
+<!-- file: docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md -->
+<!-- version: 1 -->
+
+# Réutilisation et delta attendu des POC plateforme
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.4`.
+
+## Principe
+
+Un POC plateforme est utile s'il répond à une question avec peu de code neuf.
+
+S'il nécessite immédiatement une réécriture large du jeu, cela indique soit :
+
+- une mauvaise frontière actuelle ;
+- un adapter manquant ;
+- une capability mal placée ;
+- un POC trop ambitieux.
+
+## Éléments à ne pas dupliquer
+
+### Gameplay
+
+Les crates `game-*` restent source de vérité des règles.
+
+### Assets
+
+Les assets communs et game-specific existants doivent être réutilisés.
+
+### Logging
+
+Le POC doit brancher les domaines de tracing existants plutôt que créer un logger spécifique.
+
+### Runtime provenance
+
+Chaque nouveau host/backend doit enrichir la provenance existante, pas créer un mécanisme parallèle.
+
+### Semantic input
+
+Les nouvelles entrées touch/keyboard/pointer doivent converger vers les actions sémantiques du jeu.
+
+## Éléments probablement à extraire
+
+Les POC peuvent révéler des duplications aujourd'hui acceptables dans le POC `0.1.0`.
+
+Candidats :
+
+- bridge WASM générique ;
+- frontend shell commun ;
+- input adapter Web ;
+- lifecycle Web/Tauri ;
+- asset loader Web ;
+- tracing frontend commun ;
+- fullscreen/resize ;
+- mobile lifecycle abstraction ;
+- packaging/build tooling.
+
+Aucune extraction n'est imposée avant d'avoir vu la duplication réelle.
+
+## Reflex comme sonde
+
+Reflex reste un bon POC de plateforme parce qu'il est petit.
+
+Il permet d'isoler :
+
+- pointer/touch ;
+- timing ;
+- rendu simple ;
+- WASM ;
+- bridge ;
+- startup.
+
+## Snake comme seconde sonde
+
+Snake vérifie que la solution n'est pas façonnée uniquement pour Reflex.
+
+Il ajoute :
+
+- keyboard/swipe ;
+- update continu ;
+- plusieurs entités ;
+- état de jeu persistant plus longtemps ;
+- besoin potentiel de virtual controls.
+
+## Règle de modification minimale
+
+Pour chaque POC, documenter :
+
+1. fichiers/crates réutilisés sans changement ;
+2. fichiers modifiés ;
+3. nouveaux adapters ;
+4. nouveau code strictement platform-specific ;
+5. duplications provisoires ;
+6. extractions candidates détectées.
+
+Cette comparaison servira à décider le découpage final du framework.
--- a/docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md
+++ b/docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md
@@ -0,0 +1,53 @@
+<!-- file: docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md -->
+<!-- version: 1 -->
+
+# Matrice de validation des POC plateforme
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.4`.
+
+## Dimensions communes
+
+Chaque POC doit produire des observations comparables.
+
+| Dimension              | Mesure / validation attendue                                      |
+|------------------------|-------------------------------------------------------------------|
+| Build                  | commande reproductible, dépendances, durée indicative             |
+| Artifact               | type, taille, emplacement                                         |
+| Startup                | lancement réussi, erreurs, temps indicatif                        |
+| Render                 | frame visible, resize/orientation                                 |
+| Input                  | actions principales, latence perçue, touch/keyboard/pointer       |
+| Lifecycle              | pause/resume/background/quit selon host                           |
+| Logging                | domaines visibles sur le canal plateforme                         |
+| Assets                 | chargement sans chemin hardcodé                                   |
+| Runtime provenance     | dimensions correctes                                              |
+| Packaging              | APK/AAB/app bundle/static web/binary selon cible                  |
+| Distribution           | contraintes de signature/store identifiées                        |
+| Platform integration   | faisabilité auth/ads/IAP/notifications sans implémentation finale |
+| Code reuse             | part de gameplay/adapters/front réutilisée                        |
+| Duplication            | duplication nouvelle explicitement recensée                       |
+| Maintenance            | complexité qualitative et outils nécessaires                      |
+
+## Critères de réussite
+
+Un POC n'est pas jugé uniquement sur « ça démarre ».
+
+Il doit permettre de conclure :
+
+- quel code est réutilisé ;
+- quel adapter est nécessaire ;
+- quelles dépendances sont spécifiques ;
+- quelles limitations sont structurelles ;
+- quelle stratégie mérite d'être conservée.
+
+## Critères d'arrêt
+
+Un POC peut être arrêté si :
+
+- la plateforme n'est pas accessible dans l'environnement disponible ;
+- le coût de setup dépasse l'information recherchée ;
+- une contrainte externe rend le résultat non représentatif ;
+- un POC précédent répond déjà à la question.
+
+Un arrêt documenté n'est pas un échec de version.
--- a/docs/studies/012-PLATFORM_POC_SEQUENCE.md
+++ b/docs/studies/012-PLATFORM_POC_SEQUENCE.md
@@ -0,0 +1,70 @@
+<!-- file: docs/studies/012-PLATFORM_POC_SEQUENCE.md -->
+<!-- version: 1 -->
+
+# Séquence proposée des POC plateforme
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.4`.
+
+## Principe
+
+La future série `0.3.x` pourra être dédiée aux POC plateforme, mais la numérotation exacte n'est pas encore figée.
+
+## Vague 1 — réalisable avec la base actuelle
+
+Ordre candidat :
+
+1. Tauri Android + Reflex ;
+2. Web navigateur direct + Reflex ;
+3. Tauri Desktop + Snake ;
+4. builder Android multi-ABI.
+
+Raisons :
+
+- réutilisation maximale ;
+- environnement déjà proche de celui utilisé ;
+- comparaison directe SDL / Web / Tauri ;
+- détection rapide des abstractions manquantes.
+
+## Vague 2 — plateformes natives supplémentaires
+
+Lorsque les environnements sont disponibles :
+
+1. Windows SDL natif ;
+2. macOS SDL natif ;
+3. iOS SDL natif.
+
+Ces POC servent surtout à valider la portabilité du backend SDL et du packaging.
+
+## Vague 3 — variantes mobiles alternatives
+
+Après résultat du POC Tauri Android :
+
+- Tauri iOS si pertinent ;
+- comparaison iOS SDL/Tauri si un produit Apple devient réellement prévu.
+
+## Ce que la 0.2.0 doit produire
+
+La `0.2.0` ne doit pas implémenter ces POC.
+
+Elle doit produire :
+
+- la liste retenue ;
+- les questions auxquelles chaque POC répond ;
+- les critères de validation ;
+- l'ordre recommandé ;
+- le prompt de la future session `0.3.x`.
+
+## Transition vers le prochain jeu
+
+Après la définition des POC, la fin de `0.2.0` doit étudier le prochain jeu réel.
+
+Ce jeu servira à :
+
+- prioriser les capabilities ;
+- découvrir les capacités oubliées ;
+- reclasser certains concepts ;
+- distinguer ce qui doit être implémenté avant le jeu de ce qui peut être développé avec lui.
+
+La série `0.4.x` est candidate pour porter ce prochain jeu réel et les capabilities prioritaires qu'il exige.
--- a/history/0.2.0/0-pre.3.fix.1.md
+++ b/history/0.2.0/0-pre.3.fix.1.md
@@ -0,0 +1,21 @@
+<!-- file: history/0.2.0/0-pre.3.fix.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.3.fix.1
+
+## Statut
+
+Complément d'étude validé avant ouverture de `0.2.0-0-pre.4`.
+
+## Contenu accepté
+
+- étude des bots/pseudo-IA locale ou serveur ;
+- distinction bot déterministe, recherche et modèles entraînés éventuels ;
+- identité Web canonique et providers liés ;
+- account linking ;
+- portail `games.sasedev.com` ;
+- évolution possible vers des domaines et sous-services propres aux jeux.
+
+## Suite
+
+`0-pre.4` étudie les POC plateforme à réaliser ultérieurement en maximisant la réutilisation du code `0.1.0`.