0.2.0-0-pre.3

Android/game-reflex-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 31
+// version: 32
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.2.fix.3'
+        versionName '0.2.0-0-pre.3'
     }
 
     compileOptions {

Android/game-snake-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 31
+// version: 32
 
 plugins {
     id 'com.android.application'
@@ -18,7 +18,7 @@ android {
         minSdk 21
         targetSdk 36
         versionCode 2
-        versionName '0.2.0-0-pre.2.fix.3'
+        versionName '0.2.0-0-pre.3'
     }
 
     compileOptions {

Cargo.toml

@@ -1,5 +1,5 @@
 # file: Cargo.toml
-# version: 43
+# version: 44
 
 [workspace]
 resolver = "3"
@@ -19,7 +19,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.2.0-0-pre.2.fix.3"
+version = "0.2.0-0-pre.3"
 edition = "2024"
 license = "MIT"
 repository = "https://git.sasedev.com/Sasedev/games"

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->
 
 # 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.2.fix.3`.
+Version candidate en cours de conception : `0.2.0-0-pre.3`.
 
 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.
 

deltas/0.2.0/0-pre.3.md

@@ -0,0 +1,66 @@
+<!-- file: deltas/0.2.0/0-pre.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.3
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.2.fix.3`.
+
+## Objet
+
+Compléter l'étude fonctionnelle validée en `0-pre.2.fix.3` avec deux axes manquants : adversaires pilotés/bots et architecture Web/identité/hébergement multi-jeux.
+
+## Bot / pseudo-IA
+
+L'étude couvre :
+
+- logique simple ;
+- recherche/pathfinding ;
+- modèles entraînés éventuels ;
+- bot local ;
+- bot serveur ;
+- difficulté ;
+- remplacement de joueur ;
+- bots de tests/charge ;
+- réutilisation des semantic actions ;
+- séparation entre moteur d'exécution et stratégie propre au jeu.
+
+Aucune dépendance ML n'est réservée comme obligatoire.
+
+## Web / identité / hébergement
+
+L'étude couvre :
+
+- identité canonique `PlayerId` ;
+- anonymous account ;
+- credentials propres ;
+- OAuth/OIDC ;
+- Google/Apple ;
+- Play Games/Game Center/Steam comme identities liées ;
+- account linking/merge ;
+- sessions/tokens ;
+- portail initial `games.sasedev.com` ;
+- pages/jeux sous portail commun ;
+- migration future d'un jeu vers son propre domaine ;
+- services logiques `www/auth/api/cdn/leaderboard/realtime/admin` ;
+- services spécifiques par jeu ;
+- multi-tenant logique ;
+- modular monolith initial puis séparation motivée par besoin réel ;
+- CORS/origins/OAuth redirects lors de la multiplication des domaines.
+
+## Fichiers nouveaux
+
+- `docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md` ;
+- `docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md` ;
+- `history/0.2.0/0-pre.2.fix.3.md`.
+
+## 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 : aucune implémentation runtime ou configuration de build n'est modifiée.

docs/studies/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Études
 
@@ -24,5 +24,7 @@ Les études conservent les alternatives et raisons utiles à la compréhension f
 - [`004-GAME_ARCHETYPE_PRESSURE_TEST.md`](004-GAME_ARCHETYPE_PRESSURE_TEST.md) — vérification du modèle par plusieurs familles de jeux.
 - [`005-DEPENDENCY_AND_COMPOSITION_STUDY.md`](005-DEPENDENCY_AND_COMPOSITION_STUDY.md) — dépendances autorisées et composition statique envisagée.
 - [`006-REALTIME_MULTIPLAYER_SERVER_STUDY.md`](006-REALTIME_MULTIPLAYER_SERVER_STUDY.md) — transport, session, synchronisation, autorité, resync et scaling du multijoueur temps réel.
+- [`007-GAME_AI_AND_BOT_EXECUTION_STUDY.md`](007-GAME_AI_AND_BOT_EXECUTION_STUDY.md) — adversaires pilotés par logique, bot local, bot serveur et frontières avec l'IA générative/ML.
+- [`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.

docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Inventaire fonctionnel initial
 
@@ -241,6 +241,24 @@ Plusieurs niveaux possibles :
 
 Seules les collisions réellement nécessaires seront implémentées. Un moteur physique généraliste n'est pas réservé à ce stade.
 
+### Game AI / bot control
+
+Besoins identifiés :
+
+- adversaire piloté par règles déterministes ;
+- bot local embarqué ;
+- bot serveur pour parties online ;
+- difficulté configurable ;
+- décision basée sur un état de jeu réduit ou complet ;
+- budget de calcul/tick ;
+- reproductibilité éventuelle par seed ;
+- remplacement d'un joueur déconnecté dans certains jeux ;
+- simulation de charge ou de joueurs synthétiques pour tests.
+
+Le terme « IA » ne signifie pas nécessairement machine learning. Un bot peut être une simple machine à états, un arbre de décision, du pathfinding, une recherche minimax/MCTS ou une stratégie spécialisée.
+
+Le modèle doit permettre d'exécuter la logique côté client ou côté serveur selon le jeu sans dupliquer les règles métier.
+
 ### Determinism / seeded challenge
 
 Besoins identifiés par Reflex compétitif et potentiellement puzzles/races :
@@ -331,6 +349,24 @@ Aucun provider ne doit remonter dans le kernel.
 
 ## Server services candidates
 
+### Portail Web / sites de jeux
+
+Besoins identifiés :
+
+- portail global `games.sasedev.com` ;
+- pages/catalogue des jeux ;
+- profil joueur global ;
+- pages de leaderboard ;
+- pages d'aide/support ;
+- pages légales et confidentialité ;
+- landing pages spécifiques par jeu ;
+- possibilité qu'un jeu migre ensuite vers son propre domaine ;
+- conservation de l'identité centrale malgré la séparation du site ;
+- APIs partagées et APIs spécifiques par jeu ;
+- séparation possible entre `www`, `auth`, `api`, `cdn`, `leaderboard`, `realtime`, `admin` et services propres au jeu.
+
+Le découpage DNS/deployment ne doit pas imposer le découpage interne initial. Une architecture modulaire peut commencer déployée ensemble puis être séparée.
+
 ### Services Web non temps réel
 
 Besoins identifiés :

docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Pressure test par archétypes de jeux
 
@@ -41,7 +41,7 @@ Besoins :
 - vitesse/ruleset configurable ;
 - maps ;
 - score/lives ;
-- AI éventuelle ;
+- bot/AI éventuel local ou serveur ;
 - multiplayer 2 joueurs éventuel.
 
 Conclusion provisoire :
@@ -163,7 +163,7 @@ Besoins potentiels :
 
 Conclusion provisoire :
 
-ce cas impose une architecture client/serveur nettement plus large mais ne doit pas gonfler l'engine local avant qu'un tel projet soit réellement lancé.
+ce cas impose une architecture client/serveur nettement plus large, un portail/compte durable et potentiellement des bots serveur, mais ne doit pas gonfler l'engine local avant qu'un tel projet soit réellement lancé.
 
 ## PKE avec reward crypto éventuel
 

docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Étude des dépendances et de la composition
 
@@ -186,6 +186,54 @@ Le framework peut fournir les couches techniques réutilisables sans imposer une
 
 Le serveur Web/API classique peut partager des types/protocoles avec le service realtime, mais il ne doit pas obligatoirement partager le même process ni la même cadence d'exécution.
 
+
+## Bot / AI execution
+
+Le pilotage artificiel doit emprunter autant que possible les mêmes semantic actions qu'un joueur humain :
+
+```text
+observation
+    ↓
+bot strategy
+    ↓
+semantic action
+    ↓
+game simulation
+```
+
+La stratégie peut être composée :
+
+- dans le client pour un mode offline ;
+- dans le serveur authoritative pour une partie online ;
+- dans un outil de test pour simulation/charge.
+
+Le kernel n'a pas à connaître l'algorithme utilisé.
+
+## Web et services par jeu
+
+La composition backend doit permettre un démarrage partagé puis une séparation progressive :
+
+```text
+games.sasedev.com
+    ├─ auth
+    ├─ common API
+    ├─ leaderboard
+    ├─ realtime
+    └─ game modules
+```
+
+puis, si nécessaire :
+
+```text
+game-domain
+    ├─ www
+    ├─ api
+    ├─ realtime
+    └─ cdn
+```
+
+L'identité canonique et les contrats communs doivent survivre à ce changement de déploiement.
+
 ## Online/offline
 
 La composition doit pouvoir exprimer :

docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md

@@ -0,0 +1,181 @@
+<!-- file: docs/studies/007-GAME_AI_AND_BOT_EXECUTION_STUDY.md -->
+<!-- version: 1 -->
+
+# Étude des adversaires pilotés et bots
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.3`.
+
+## Objectif
+
+Prévoir des adversaires contrôlés par le programme sans supposer qu'ils doivent être :
+
+- du machine learning ;
+- embarqués dans le client ;
+- dépendants d'un provider externe ;
+- spécifiques à une seule plateforme.
+
+Le besoin générique est :
+
+> produire une décision de joueur artificiel à partir d'un état de jeu autorisé.
+
+## Familles de logique
+
+### Règles simples
+
+Exemples :
+
+- réflexes basiques ;
+- comportement scripté ;
+- probabilités pondérées ;
+- machine à états.
+
+Adapté à :
+
+- Snake simple ;
+- ennemis d'arcade ;
+- tutorial opponent ;
+- bots de remplissage.
+
+### Recherche / planification
+
+Exemples :
+
+- BFS/A* ;
+- minimax ;
+- alpha-beta ;
+- MCTS ;
+- heuristiques de navigation.
+
+Adapté à :
+
+- puzzles ;
+- jeux de plateau ;
+- certains jeux tactiques.
+
+### Modèles entraînés
+
+À réserver seulement lorsqu'un projet réel le justifie :
+
+- modèle supervisé ;
+- reinforcement learning ;
+- réseau neuronal ;
+- XGBoost/LightGBM pour décisions tabulaires.
+
+Le framework de jeu ne doit pas dépendre d'un framework ML tant qu'aucun consommateur concret ne l'exige.
+
+## Contrat conceptuel
+
+Un bot pourrait consommer :
+
+```text
+GameObservation
+BotContext
+DifficultyProfile
+DecisionBudget
+```
+
+et produire :
+
+```text
+SemanticAction
+```
+
+ou une séquence courte d'actions.
+
+Le contrat exact n'est pas figé.
+
+## Local vs serveur
+
+### Bot local
+
+Avantages :
+
+- fonctionne offline ;
+- latence faible ;
+- pas de coût serveur.
+
+Risques :
+
+- logique visible/modifiable côté client ;
+- comportement potentiellement différent selon version ;
+- impossible d'en faire une autorité fiable pour compétition.
+
+### Bot serveur
+
+Avantages :
+
+- comportement centralisé ;
+- version contrôlée ;
+- utile pour matchmaking/remplacement de joueurs ;
+- peut partager la simulation authoritative.
+
+Risques :
+
+- coût CPU ;
+- besoin réseau ;
+- complexité de scaling.
+
+## Règle d'ownership candidate
+
+La stratégie de bot dépend du jeu ou d'un game-system spécialisé.
+
+Le mécanisme d'exécution générique peut être réutilisable :
+
+```text
+game simulation
+      ↓
+observation
+      ↓
+bot strategy
+      ↓
+semantic action
+```
+
+Le bot ne doit pas appeler directement l'input physique ni modifier l'état interne par un chemin privilégié si un joueur humain passe par des semantic actions.
+
+## Difficulté
+
+La difficulté peut être obtenue par :
+
+- profondeur de recherche ;
+- délai de réaction ;
+- précision ;
+- bruit ;
+- accès limité à l'information ;
+- heuristique plus ou moins forte ;
+- budget CPU/tick.
+
+Éviter de tricher implicitement en donnant au bot des informations invisibles au joueur, sauf si le game design l'assume explicitement.
+
+## Remplacement de joueur
+
+Cas utile en multiplayer :
+
+- joueur déconnecté ;
+- lobby incomplet ;
+- partie d'entraînement ;
+- remplissage temporaire.
+
+Le remplacement doit être une décision du jeu/session, pas une règle imposée par le moteur.
+
+## Tests
+
+Les bots peuvent aussi servir à :
+
+- tests de longues parties ;
+- fuzzing de gameplay ;
+- génération de trajectoires ;
+- tests de charge serveur ;
+- validation de déterminisme.
+
+Un bot de test peut être distinct d'un bot destiné au joueur final.
+
+## Questions ouvertes
+
+- faut-il une API générique `BotController` ou rester game-specific au début ?
+- où stocker les profils de difficulté ?
+- comment garantir le même comportement client/serveur si la logique est partagée ?
+- quand extraire pathfinding/recherche vers des game-systems réutilisables ?
+- comment versionner la stratégie d'un bot dans un match replayable ?

docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md

@@ -0,0 +1,282 @@
+<!-- file: docs/studies/008-WEB_IDENTITY_AND_GAME_HOSTING_STUDY.md -->
+<!-- version: 1 -->
+
+# Étude Web, identité et hébergement des jeux
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.3`.
+
+## Objectif
+
+Permettre un démarrage simple sous une plateforme commune puis une évolution vers des sites et services propres à certains jeux sans casser l'identité joueur.
+
+## Identité canonique
+
+Le backend games.sasedev doit posséder un identifiant joueur canonique indépendant des providers externes.
+
+Conceptuellement :
+
+```text
+PlayerId
+  ├─ anonymous device identity
+  ├─ email/password ou passwordless
+  ├─ Google identity
+  ├─ Apple identity
+  ├─ Play Games identity
+  ├─ Steam identity
+  └─ autres providers futurs
+```
+
+Un provider externe est une identité liée, pas la clé primaire du joueur.
+
+## Modes d'authentification à prévoir
+
+### Anonymous
+
+Cas :
+
+- découverte immédiate du jeu ;
+- première partie sans création de compte ;
+- fonctionnement offline ou semi-online.
+
+Doit permettre si nécessaire :
+
+- création d'un profil temporaire ;
+- migration vers un compte durable ;
+- conservation de progression lors de l'upgrade.
+
+### Credentials propres
+
+Options à étudier :
+
+- email + mot de passe ;
+- username + mot de passe ;
+- magic link ;
+- passkey/WebAuthn.
+
+Le choix final dépendra des besoins sécurité/UX.
+
+### OAuth / OpenID Connect
+
+Providers plausibles :
+
+- Google ;
+- Apple ;
+- autres comptes sociaux si pertinents.
+
+Le backend doit valider les tokens/provider claims puis lier l'identité externe à son `PlayerId`.
+
+### Platform identities
+
+Exemples :
+
+- Google Play Games ;
+- Apple Game Center ;
+- Steam.
+
+Ces identités peuvent faciliter sign-in, achievements ou leaderboard mais ne remplacent pas l'identité canonique globale.
+
+## Account linking
+
+Cas à prévoir :
+
+- anonymous → compte durable ;
+- Google + Apple sur le même joueur ;
+- appareil perdu puis récupération ;
+- changement de provider ;
+- conflit lorsque deux providers correspondent déjà à deux comptes distincts.
+
+Le merge de comptes doit être explicite et sécurisé.
+
+## Sessions
+
+Besoins :
+
+- access token court ;
+- refresh/session token ;
+- révocation ;
+- liste des devices/sessions éventuellement ;
+- logout global ou local ;
+- rotation ;
+- protection CSRF/cookies pour Web selon architecture ;
+- stockage sécurisé côté apps natives.
+
+Le détail cryptographique sera étudié séparément avant implémentation.
+
+## Portail initial
+
+Déploiement initial plausible :
+
+```text
+games.sasedev.com
+```
+
+Responsabilités possibles :
+
+- catalogue ;
+- login/signup ;
+- compte joueur ;
+- pages des jeux ;
+- leaderboards ;
+- support ;
+- liens vers stores ;
+- jeu Web pour les produits compatibles ;
+- administration séparée.
+
+Les premiers jeux peuvent être servis sous :
+
+```text
+games.sasedev.com/games/snake
+games.sasedev.com/games/reflex
+```
+
+ou équivalent.
+
+Le chemin exact n'est pas encore décidé.
+
+## Évolution vers un site propre
+
+Un jeu devenu suffisamment important peut avoir :
+
+```text
+snake.example-game-domain.tld
+```
+
+ou un domaine propre.
+
+Le déplacement ne doit pas imposer :
+
+- nouveau compte joueur ;
+- nouvelle base d'identité ;
+- duplication des providers OAuth ;
+- incompatibilité des leaderboards/progression.
+
+Le site propre consomme les services communs via des APIs versionnées.
+
+## Sous-services
+
+Découpage logique candidat :
+
+```text
+www.games.sasedev.com
+auth.games.sasedev.com
+api.games.sasedev.com
+cdn.games.sasedev.com
+leaderboard.games.sasedev.com
+realtime.games.sasedev.com
+admin.games.sasedev.com
+```
+
+et, pour un jeu spécifique :
+
+```text
+www.<game-domain>
+api.<game-domain>
+realtime.<game-domain>
+cdn.<game-domain>
+```
+
+Ce sont des frontières logiques possibles, pas une obligation de créer immédiatement tous ces DNS/process.
+
+## Global vs game-specific
+
+Services globalement partageables :
+
+- auth/identity ;
+- account/profile ;
+- entitlement général éventuel ;
+- catalogue ;
+- administration centrale ;
+- common CDN assets éventuels.
+
+Services souvent game-specific :
+
+- gameplay API ;
+- matchmaking ;
+- realtime simulation ;
+- rulesets ;
+- game inventory/progression spécialisée ;
+- events/seasons ;
+- maps/assets propres au jeu.
+
+Certains services, comme leaderboard, peuvent avoir une API générique et une configuration par jeu.
+
+## Multi-tenant logique
+
+Le backend commun doit pouvoir distinguer :
+
+- `game_id` ;
+- environment ;
+- protocol/version ;
+- player ;
+- product/platform.
+
+Éviter de dupliquer tout le backend par jeu avant qu'une isolation réelle ne soit nécessaire.
+
+## Hébergement et découpage physique
+
+Étape initiale plausible :
+
+```text
+modular monolith
+```
+
+avec modules clairement séparés.
+
+Évolution possible :
+
+```text
+auth service
+API service
+realtime service
+leaderboard service
+game-specific services
+```
+
+La séparation physique est motivée par :
+
+- charge ;
+- sécurité ;
+- cycle de déploiement ;
+- isolation de panne ;
+- besoins réseau ;
+- ownership.
+
+Pas par recherche de microservices pour eux-mêmes.
+
+## Web game hosting
+
+Un jeu Web/WASM peut être :
+
+- servi directement par le portail global ;
+- servi par son propre site ;
+- embarqué dans une page Tauri pour certains produits ;
+- télécharger ses assets depuis un CDN séparé.
+
+Le build jeu doit rester indépendant du hostname final.
+
+## CORS / origins / OAuth redirects
+
+Le passage d'un domaine global à des domaines propres impose de prévoir :
+
+- origins autorisées ;
+- callback URLs OAuth ;
+- cookies/domain policy ;
+- CORS ;
+- CSP ;
+- token audience ;
+- deep links/app links éventuels.
+
+Ces points doivent être configurables et non hardcodés dans le gameplay.
+
+## Questions ouvertes
+
+- quel provider d'identité implémenter en premier ?
+- anonymous account server-side dès le début ou seulement local ?
+- email/password, magic link ou passkey ?
+- cookies de session pour Web vs bearer tokens pour apps natives ?
+- comment gérer account merge ?
+- quel découpage initial entre portail, auth, API et realtime ?
+- quels services doivent être multi-game dès V1 ?
+- comment versionner les APIs et protocoles par jeu ?

history/0.2.0/0-pre.2.fix.3.md

@@ -0,0 +1,27 @@
+<!-- file: history/0.2.0/0-pre.2.fix.3.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.2.fix.3
+
+## Statut
+
+Étude fonctionnelle initiale validée avant ouverture de `0.2.0-0-pre.3`.
+
+## Contenu accepté
+
+- inventaire fonctionnel initial ;
+- séparation kernel / capability / game-system / platform adapter / provider / server service / tooling / game-specific ;
+- matrice conceptuelle des plateformes et backends ;
+- pressure tests par archétypes de jeux ;
+- dépendances et composition statique ;
+- étude du serveur realtime, snapshots/deltas, resync, authoritative state et scaling ;
+- conventions de tableaux Markdown corrigées et validées par audit.
+
+## Suite
+
+`0-pre.3` complète l'étude avec :
+
+- adversaires pilotés/bots local ou serveur ;
+- identité Web multi-provider ;
+- portail commun puis sites propres aux jeux ;
+- séparation progressive des sous-services.