0.2.0

Android/game-reflex-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-reflex-poc/build.gradle
-// version: 24
+// version: 45
 
 plugins {
     id 'com.android.application'
@@ -17,8 +17,8 @@ android {
         applicationId 'com.sasedev.games.reflex'
         minSdk 21
         targetSdk 36
-        versionCode 1
-        versionName '0.1.0'
+        versionCode 2
+        versionName '0.2.0'
     }
 
     compileOptions {

Android/game-snake-poc/build.gradle

@@ -1,5 +1,5 @@
 // file: Android/game-snake-poc/build.gradle
-// version: 24
+// version: 45
 
 plugins {
     id 'com.android.application'
@@ -17,8 +17,8 @@ android {
         applicationId 'com.sasedev.games.snake'
         minSdk 21
         targetSdk 36
-        versionCode 1
-        versionName '0.1.0'
+        versionCode 2
+        versionName '0.2.0'
     }
 
     compileOptions {

CHANGELOG.md

@@ -1,16 +1,27 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 8 -->
+<!-- version: 12 -->
 
 # Changelog
 
+## 0.2.0 — conception modulaire, POC et Uroburas
+
+- Gouvernance documentaire renforcée : catégories `ideas/studies/architecture/rules`, immutabilité des deltas, conventions de statuts et workflow de session/version.
+- Architecture durable séparant engine kernel, technical capabilities, game-systems, games, platform adapters, providers, server services et tooling.
+- Trajectoire POC `0.3.x` définie avec Snake comme jeu-sonde pour SDL, Web/WASM, Tauri et transports realtime.
+- Architecture réseau de référence : Actix Web/Maud/Fluent/Lettre pour Web/API, WebSocket/tokio-tungstenite baseline, WebTransport/QUIC candidat, gRPC/Tonic conditionnel server-to-server.
+- Asset delivery auto-hébergé, compatible HTTP/2 et HTTP/3 selon disponibilité, avec séparation logique puis physique progressive.
+- Cible d'exploitation préférée : Debian Stable, actuellement Debian 13 `trixie`, sans dépendance métier à une version précise.
+- Spécification fonctionnelle et architecture cible initiales de Uroburas, avec ordre Mode 1 Challenge → Mode 3 Persistent Battle Royale → Mode 2 PvP Battles.
+- Classification des besoins Uroburas afin d'éviter une crate jeu monolithique.
+- Première trajectoire Uroburas réservant grid/tilemap toroïdale, obstacles, stages, vies, score, caméra, assets téléchargeables, auth, rewarded ads, Hall of Fame et échanges client/serveur sécurisés/versionnés.
+
 ## 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.
+- réservation de la direction `0.2.0` pour concevoir progressivement le framework modulaire avant toute extension fonctionnelle majeure.
 
 ## 0.1.0-3-rc.1 — 2026-09-17
 
@@ -20,59 +31,4 @@
 - entrée en phase RC centrée sur la reproductibilité des builds de release, les artefacts de distribution et la documentation de livraison ;
 - ajout d'une matrice RC et d'une gate workspace complète avant promotion vers `0.1.0`.
 
-## 0.1.0-2-beta.1 — 2026-09-17
-
-- validation de `1-alpha.2.fix.5` avec Reflex exécuté dans Tauri/WebView/WASM via Vite + TypeScript ;
-- validation du tracing unifié Rust/TypeScript et de la sortie `Escape` via le contrat moteur commun ;
-- passage en phase beta, désormais centrée sur la stabilisation, le packaging et les tests multi-appareils ;
-- ajout d'une matrice de validation Desktop SDL3, Tauri/WASM, Android AVD x86_64 et Android ARM64 réel ;
-- ajout d'un audit en lecture seule des frontières statiques nécessaires aux distributions ;
-- formalisation des gates de packaging Desktop natif, Tauri et Android beta.
-
-## 0.1.0-1-alpha.1 — 2026-09-16
-
-- validation de la fin de phase `0-pre.*` avec Snake jouable sur Desktop et Galaxy S9+ ARM64 ;
-- stabilisation du contrat de sortie `QuitRequest` / `QuitDecision` introduit pendant les derniers correctifs `0-pre.11` ;
-- introduction de `RuntimeProvenance` dans `engine-v1-platform-api` ;
-- séparation explicite entre famille de plateforme, classe de device, exécution native/WASM, hôte runtime et profil d'entrée ;
-- préparation des futurs leaderboards/Hall of Fame pour segmenter les scores selon l'environnement sans imposer de comparaison automatique ;
-- planification d'un POC Web/WASM dans Tauri comme prochain jalon alpha.
-
-## 0.1.0-0-pre.4 — 2026-09-16
-
-- validation de `0-pre.3` enregistrée avec suite workspace complète et smokes Desktop propres ;
-- déplacement des tests unitaires hors `src/` vers `unit_tests/` et formalisation de `tests/` pour intégration/environnement ;
-- ajout d’un audit empêchant le retour de corps de tests sous `src/` ;
-- adoption des tests Cargo ciblés par défaut, la suite workspace complète devenant une gate lourde périodique ;
-- `cargo fmt --all` devient obligatoire avant la gate lorsqu’un delta modifie du Rust, sans incrément d’en-tête pour les seules modifications rustfmt ;
-- introduction de `game-logging-lib` avec `tracing`, `tracing-subscriber` et `tracing-appender` ;
-- initialisation du tracing dans les runners Desktop et helper de tracing local pour les tests.
-
-## 0.1.0-0-pre.3 — 2026-09-16
-
-- validation utilisateur de `0.1.0-0-pre.2` avec formatage, audits, check, Clippy strict et tests workspace propres ;
-- introduction de `EngineFrame`, `InputState`, `EngineGame` et `FixedStepRunner` comme première boucle moteur indépendante de SDL3 ;
-- branchement des deux POC et des deux runners Desktop sur cette boucle commune ;
-- introduction d'un état explicite `Available` / `Disabled` / `Unsupported` pour les services plateforme optionnels et d'une déclaration de capacités de monétisation ;
-- documentation de la monétisation optionnelle par plateforme, y compris distinction Android, Web et Desktop ;
-- documentation du binaire Desktop SDL3 comme défaut et d'une variante Tauri optionnelle sans duplication du gameplay ;
-- formalisation de la validation Cargo par l'utilisateur, de l'enregistrement de la validation du delta précédent et du passage automatique au delta suivant ou à un `.fix.N` selon le résultat.
-
-## 0.1.0-0-pre.2 — 2026-09-15
-
-- intégration de l'architecture de référence dans une documentation thématique durable ;
-- ajout des objectifs projet, classification des jeux, abstraction SDL3 multi-plateforme, contrôles, assets, évolution moteur, monétisation et services en ligne ;
-- ajout d'une crate binaire Desktop par POC, chacune consommant exclusivement la crate lib du jeu correspondant ;
-- ajout de la politique normative des commandes Cargo, audits, runners, Android, Web et Git ;
-- mise à jour de l'index documentaire, des contrats de fichiers, de la roadmap et des gates.
-
-## 0.1.0-0-pre.1 — 2026-09-15
-
-- création du workspace Cargo multi-crates ;
-- introduction de la génération `engine-v1` ;
-- création de deux POC structurels Reflex et Snake ;
-- séparation stricte des assets hors crates ;
-- création de la structure Android Java commune et spécifique par jeu ;
-- adaptation des règles et audits issus de l'expérience KSP ;
-- adoption du cycle SemVer `pre -> alpha -> beta -> rc -> stable` avec correctifs `.fix.N` ;
-- adoption des livraisons par archives delta.
+Les détails des phases `pre`, `alpha`, `beta` et de leurs correctifs sont conservés dans `deltas/0.1.0/` et `history/0.1.0/`.

Cargo.toml

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

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 6 -->
+<!-- version: 25 -->
 
 # games.sasedev
 
@@ -23,7 +23,9 @@ Workspace expérimental puis productif pour des jeux multiplateformes principale
 
 ## Baseline
 
-Version courante : `0.1.0-1-alpha.1`.
+Version stable de référence : `0.1.0`.
+
+Version candidate en cours de conception : `0.2.0`.
 
 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.
 

ROADMAP.md

@@ -1,27 +1,36 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 14 -->
+<!-- version: 19 -->
 
 # Roadmap
 
+## Légende
+
+- `( )` — planned ;
+- `(x)` — completed ;
+- `(d)` — deferred ;
+- `(c)` — cancelled.
+
+Les marqueurs qualifient une ligne de scope. Une même version peut donc apparaître plusieurs fois si une partie est livrée, une partie reportée et une autre annulée.
+
 ## 0.1.0 — Fondation POC
 
-- [x] `0-pre.1` — squelette du workspace, règles, architecture, versions, assets, Java Android commun/spécifique et deux crates POC.
-- [x] `0-pre.2` — consolidation documentaire issue de l'architecture de référence, runners Desktop par jeu et politique normative des commandes.
-- [x] `0-pre.3` — première boucle moteur exécutable Desktop : temps, input abstrait, capacités de monétisation optionnelles et état de jeu minimal via les runners.
-- [x] `0-pre.4` — architecture de tests hors `src/`, stratégie de tests ciblés et socle `tracing`/`tracing-subscriber`/`tracing-appender`.
-- [x] `0-pre.5` — intégration SDL3 Desktop réelle et premier rendu POC Reflex.
-- [x] `0-pre.6` — fondation Gradle Android, SDL3 AAR, Activity Java commune et politique de fenêtre Desktop redimensionnable.
-- [x] `0-pre.7` — compilation Rust Android `cdylib`, point d'entrée SDL Android et premier lancement APK sur appareil/émulateur.
-- [x] `0-pre.8` — bridge Java/JNI minimal et input tactile Android.
-- [x] `0-pre.9` — assets communs + spécifiques empaquetés sans copie dans les crates.
-- [x] `0-pre.10` — POC Reflex jouable Desktop + Android.
-- [x] `0-pre.11` — POC Snake jouable et validation de la réutilisation du moteur.
-- [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.
-- [x] `3-rc.1` — candidat de release du socle 0.1.0.
-- [x] `0.1.0` — première baseline stable du framework POC.
+- (x) `0.1.0` — squelette du workspace, règles, architecture, versions et assets.
+- (x) `0.1.0` — moteur V1 POC, boucle de jeu, input abstrait et rendu SDL3 minimal.
+- (x) `0.1.0` — Reflex et Snake jouables comme POC de réutilisation.
+- (x) `0.1.0` — Desktop SDL3 natif, Android SDL3/Java/JNI et Tauri/WebView/WASM Reflex.
+- (x) `0.1.0` — tracing commun, provenance runtime, packaging et validation multi-appareils.
+
+Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `history/0.1.0/`.
 
 ## 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.
+- (x) `0.2.0` — fixer la gouvernance documentaire, la nomenclature et le cycle de maturation des idées et décisions.
+- (x) `0.2.0` — inventorier et réserver les capabilities déjà justifiées sans les implémenter prématurément.
+- ( ) `0.2.0` — définir les couches, les dépendances autorisées et la frontière entre kernel, capability, plateforme, provider, système de jeu et service.
+- ( ) `0.2.0` — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture.
+- ( ) `0.2.0` — définir le modèle de composition statique, le manifest produit/jeu et l'architecture cible des crates.
+- ( ) `0.2.0` — définir la trajectoire d'implémentation progressive des versions suivantes seulement après revue de la conception.
+- (x) `0.2.0` — consolider les études acceptées en architecture/règles durables, notamment ownership, réseau, Uroburas et POC, puis fermer les points encore candidats.
+- (x) `0.2.0` — formaliser la stratégie réseau : Actix Web pour le Web/API, asset delivery auto-hébergé H2/H3, WebSocket baseline et WebTransport/QUIC candidat.
+- (x) `0.2.0` — préparer une trajectoire `0.3.x` dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde.
+- (x) `0.2.0` — préparer la trajectoire `0.4.x` Uroburas Mode 1 et le prompt de session associé après gel de la conception.

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Index normatif games.sasedev
 
@@ -15,7 +15,10 @@ Les règles détaillées sont maintenues sous `docs/rules/` et sont cumulatives
 4. [`docs/rules/RULES_DOCUMENTATION.md`](docs/rules/RULES_DOCUMENTATION.md) — règles Markdown et cycle documentaire ;
 5. [`docs/rules/FILE_CONTRACTS.md`](docs/rules/FILE_CONTRACTS.md) — responsabilités des principales familles de fichiers ;
 6. [`docs/rules/VERSION_WORKFLOW.md`](docs/rules/VERSION_WORKFLOW.md) — SemVer, niveaux de maturité, fixes, deltas et livraisons ;
-7. [`docs/rules/RULES_COMMANDS.md`](docs/rules/RULES_COMMANDS.md) — politique d’exécution des commandes Cargo, audits, runners, Android, Web et Git.
+7. [`docs/rules/RULES_COMMANDS.md`](docs/rules/RULES_COMMANDS.md) — politique d’exécution des commandes Cargo, audits, runners, Android, Web et Git ;
+8. [`docs/rules/RULES_VALIDATION_MATRIX.md`](docs/rules/RULES_VALIDATION_MATRIX.md) — matrice évolutive des commandes, dépendances de validation et politiques de nettoyage ;
+9. [`docs/rules/RULES_SESSION_PLANNING.md`](docs/rules/RULES_SESSION_PLANNING.md) — cadrage `pre.1`, dimensionnement des sessions et contrat des prompts de reprise ;
+10. [`docs/rules/RULES_SERVER_HOSTING.md`](docs/rules/RULES_SERVER_HOSTING.md) — contraintes durables de portabilité et préférence d'auto-hébergement.
 
 ## Hiérarchie
 

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

@@ -1,7 +1,6 @@
 {
   "$schema": "https://schema.tauri.app/config/2",
   "productName": "Reflex POC Tauri",
-  "version": "0.1.0",
   "identifier": "com.sasedev.games.reflex.tauri",
   "build": {
     "beforeDevCommand": {
@@ -31,6 +30,8 @@
   },
   "bundle": {
     "active": false,
-    "icon": ["icons/icon.png"]
+    "icon": [
+      "icons/icon.png"
+    ]
   }
 }

deltas/0.2.0/0-pre.1.fix.1.delete.txt

@@ -0,0 +1,3 @@
+docs/ideas/README.md
+docs/studies/README.md
+history/README.md

deltas/0.2.0/0-pre.1.fix.1.md

@@ -0,0 +1,121 @@
+<!-- file: deltas/0.2.0/0-pre.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.1.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.1`.
+
+La prerelease précédente reste une candidate documentaire non validée. Ce fix corrige et complète les règles de gouvernance avant toute progression vers `0-pre.2`.
+
+## Documentation et nomenclature
+
+- adoption de `000-README.md` comme point d'entrée des répertoires documentaires multi-fichiers ;
+- renommage de `docs/ideas/README.md`, `docs/studies/README.md` et `history/README.md` ;
+- généralisation des marqueurs `( )`, `(x)`, `(d)`, `(c)` à toute liste durable de tâches ou d'état, pas seulement au ROADMAP ;
+- conservation des listes descriptives simples sans marqueur artificiel.
+
+## Plateformes
+
+La conception réserve désormais explicitement :
+
+- Desktop : Linux, Windows, macOS ;
+- Mobile : Android, iOS ;
+- Web : navigateur/WASM.
+
+Téléphone et tablette restent des classes de device séparées de l'OS et du backend technique. SDL3 reste le backend natif de référence du POC sans devenir l'identité architecturale d'une plateforme.
+
+## Tauri et versions
+
+- `tauri.conf.json` n'embarque plus de version produit et laisse Tauri utiliser la version Cargo ;
+- `package.json` n'est plus synchronisé à chaque `pre.N` / `.fix.N` et revient à la dernière version frontend significative `0.1.0` pendant cette phase documentaire ;
+- Cargo reste la source canonique de version produit.
+
+## Workflow RC et prompt suivant
+
+- une RC est fonctionnellement gelée ;
+- les bugfixes, corrections de tests, packaging, sécurité et défauts de release peuvent modifier du code sans retour automatique en beta ;
+- une réouverture fonctionnelle de la RC nécessite de revenir à une phase de développement adaptée, normalement beta ;
+- le prompt de la version suivante devient recommandé après validation de la première RC réellement gelée, puis peut être affiné jusqu'à la stable.
+
+## Planification des versions de code
+
+Le cycle conceptuel est :
+
+```text
+PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
+```
+
+Ces phases n'imposent pas une prerelease chacune. Une petite version peut combiner PLAN et première implémentation dans `pre.1`; une version lourde peut réserver `pre.1` à la décomposition.
+
+## Matrice de validation
+
+Ajout de `docs/rules/RULES_VALIDATION_MATRIX.md` avec :
+
+- identifiants stables `CMD-*` ;
+- dépendances entre commandes ;
+- portée ciblée par crate ;
+- propagation vers les consommateurs impactés ;
+- gates Desktop, Tauri et Android ;
+- règles beta/RC ;
+- commandes de maintenance disque.
+
+## Politique Cargo clean
+
+Le besoin de contrôle disque est reconnu explicitement.
+
+`cargo clean` complet peut être planifié périodiquement à un jalon de cycle afin d'éviter l'accumulation de dizaines ou centaines de Go sous `../builds/sasedev-games/target`.
+
+Entre deux cleans complets, utiliser si pertinent :
+
+```bash
+cargo clean -p <package>
+cargo clean --release
+cargo clean --profile <profile>
+cargo clean --target <triple>
+cargo clean --dry-run --verbose
+```
+
+Il n'existe pas de contrat projet consistant à conserver automatiquement « uniquement la dernière génération utile » des artefacts Cargo : les nettoyages ciblés ou complets sont donc des opérations explicites.
+
+## Suppressions nécessaires
+
+Un overlay ZIP ne supprime pas les anciens fichiers. Après extraction du delta, appliquer :
+
+```bash
+while IFS= read -r path; do
+    rm -rf -- "$path"
+done < deltas/0.2.0/0-pre.1.fix.1.delete.txt
+```
+
+## Validation automatique
+
+```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
+```
+
+La suppression de `version` dans `tauri.conf.json` modifie une configuration de build. Une vérification Tauri est donc recommandée avant validation définitive du fix :
+
+```bash
+(cd crates/apps/game-reflex-poc-tauri && cargo tauri build)
+```
+
+Aucun smoke gameplay supplémentaire n'est requis si le build Tauri est propre, car le gameplay et le runtime ne sont pas modifiés.
+
+## Validation humaine
+
+Relire prioritairement :
+
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/rules/RULES_COMMANDS.md` ;
+- `docs/rules/RULES_VALIDATION_MATRIX.md` ;
+- `docs/rules/VERSION_WORKFLOW.md` ;
+- `docs/rules/FILE_CONTRACTS.md` ;
+- `docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md` ;
+- `docs/rules/RULES_PROJECT.md` ;
+- `prompts/001-V0_2_0_START_PROMPT.md`.
+
+Ce fix ne valide toujours pas le catalogue fonctionnel `0.2.0` : la progression vers `0-pre.2` dépend de la revue humaine de cette gouvernance.

deltas/0.2.0/0-pre.1.fix.2.md

@@ -0,0 +1,63 @@
+<!-- file: deltas/0.2.0/0-pre.1.fix.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.1.fix.2
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.1.fix.1`.
+
+## Objet
+
+Ce fix formalise l'immuabilité des deltas, le contrat des manifests de suppression et l'incrément obligatoire des versions d'en-tête.
+
+Les deltas déjà livrés ne sont pas modifiés.
+
+## Deltas immuables
+
+- un fichier `deltas/**/*.md` livré est immuable sur le fond ;
+- seules les corrections non sémantiques de forme peuvent toucher le fichier existant ;
+- toute correction de forme autorisée incrémente son en-tête `version` ;
+- toute correction sémantique ou tout ajout produit un nouveau delta ou `.fix.N`.
+
+## Manifests `*.delete.txt`
+
+Les manifests de suppression sont désormais un contrat documenté :
+
+- un chemin relatif à la racine par ligne ;
+- aucune commande shell dans le manifest ;
+- le delta Markdown associé décrit la raison de chaque groupe de suppressions ;
+- le delta Markdown associé fournit la procédure d'application ;
+- toute modification sémantique des suppressions passe par un nouveau delta/fix.
+
+## Versions d'en-tête
+
+Toute modification réelle d'un fichier versionné incrémente son en-tête `version`.
+
+Les seuls changements qui n'imposent pas cet incrément sont les transformations purement mécaniques réalisées par un formatter officiel, sans autre modification réelle.
+
+Un renommage qui modifie l'en-tête `file:` compte comme une modification réelle.
+
+## Fichiers modifiés par ce fix
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/rules/FILE_CONTRACTS.md` ;
+- `docs/rules/VERSION_WORKFLOW.md` ;
+- `docs/rules/RULES_PROJECT.md` ;
+- `docs/rules/RULES_VALIDATION_MATRIX.md`.
+
+Tous les fichiers ci-dessus qui possèdent un en-tête de version ont été incrémentés.
+
+## 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
+```
+
+Aucun code Rust, Java ou TypeScript n'est modifié dans ce fix.

deltas/0.2.0/0-pre.1.md

@@ -0,0 +1,65 @@
+<!-- file: deltas/0.2.0/0-pre.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.1
+
+## Base
+
+Base déclarée : `0.1.0`.
+
+## Objet
+
+Première prerelease documentaire de `0.2.0`.
+
+Cette tranche ne fige pas encore le catalogue complet des capabilities ni l'architecture cible du framework. Elle fixe d'abord la méthode de conception et de documentation qui sera utilisée pour les prereleases suivantes.
+
+## Contenu
+
+- passage de la version workspace et des métadonnées produit à `0.2.0-0-pre.1` ;
+- correction de la version courante affichée dans `README.md` ;
+- renforcement de `RULES_DOCUMENTATION.md` ;
+- création des contrats `docs/ideas/` et `docs/studies/` ;
+- adoption des marqueurs ROADMAP `( )`, `(x)`, `(d)`, `(c)` ;
+- définition des reports et annulations partiels avec conservation de l'historique de planning ;
+- migration du ROADMAP existant vers la nouvelle convention ;
+- limitation du CHANGELOG aux jalons RC et stables ;
+- migration ponctuelle du CHANGELOG `0.1.0`, les détails retirés restant dans `deltas/` et `history/` ;
+- définition de la maturation des idées et capabilities ;
+- formalisation de la validation humaine des versions documentaires ;
+- réécriture du prompt `0.2.0` pour imposer une conception progressive par prereleases.
+
+## Hors scope
+
+Cette prerelease ne doit pas encore :
+
+- produire le catalogue exhaustif des capabilities ;
+- figer la matrice complète des plateformes ;
+- figer l'architecture future des crates ;
+- planifier définitivement les versions d'implémentation ;
+- créer de nouvelles crates de capability ;
+- modifier le gameplay ou les runtimes existants.
+
+## Validation automatique
+
+```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 ou smoke test n'est requise pour accepter le fond de cette prerelease : elle ne modifie aucun source Rust, Java, TypeScript ou contrat runtime. La cohérence de version des manifests doit toutefois être relue.
+
+## Validation humaine
+
+La prerelease n'est considérée validée qu'après revue explicite des documents, notamment :
+
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/rules/FILE_CONTRACTS.md` ;
+- `docs/rules/VERSION_WORKFLOW.md` ;
+- `ROADMAP.md` ;
+- `CHANGELOG.md` ;
+- `docs/ideas/000-README.md` ;
+- `docs/studies/000-README.md` ;
+- `prompts/001-V0_2_0_START_PROMPT.md`.
+
+Les omissions, ambiguïtés ou règles contestées doivent être corrigées dans `0.2.0-0-pre.1.fix.N` si elles invalident cette candidate, ou traitées dans `0-pre.2` lorsqu'elles constituent la suite normale de conception.

deltas/0.2.0/0-pre.2.fix.1.md

@@ -0,0 +1,80 @@
+<!-- file: deltas/0.2.0/0-pre.2.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.2.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.2`.
+
+Le delta `0-pre.2.md` reste immuable.
+
+## Objet
+
+Corriger la présentation normative du tableau de plateformes et compléter l'étude des capacités serveur nécessaires au multijoueur temps réel.
+
+## Tableau plateforme
+
+`docs/studies/003-PLATFORM_CAPABILITY_STUDY.md` utilise désormais des marqueurs d'alignement Markdown explicites.
+
+La convention documentaire est précisée :
+
+- colonne textuelle : `:---` ;
+- colonne numérique : `---:` ;
+- valeur courte réellement destinée à être centrée : `:---:`.
+
+Le tableau actuel de plateformes ne contenant que des valeurs textuelles, toutes ses colonnes sont alignées explicitement à gauche.
+
+## Realtime multiplayer
+
+L'inventaire serveur est complété afin de distinguer :
+
+- API/Web non temps réel ;
+- lobby/matchmaking/session control ;
+- realtime data plane ;
+- synchronisation client ;
+- chat/presence.
+
+Une étude dédiée couvre notamment :
+
+- WebSocket/gateway ;
+- tick serveur ;
+- ingestion et sequencing des inputs ;
+- état authoritative ;
+- snapshots et deltas ;
+- revisions/acks ;
+- interpolation/prediction/reconciliation ;
+- rollback lorsque nécessaire ;
+- reconnect/resync ;
+- rooms et session routing ;
+- interest management ;
+- backpressure ;
+- persistence hors boucle temps réel ;
+- observability ;
+- scaling.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/studies/000-README.md` ;
+- `docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md` ;
+- `docs/studies/003-PLATFORM_CAPABILITY_STUDY.md` ;
+- `docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md` ;
+- `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md` ;
+- `docs/studies/006-REALTIME_MULTIPLAYER_SERVER_STUDY.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 supplémentaire n'est requise : aucun code runtime ou configuration de build n'est modifié hors métadonnées de version.

deltas/0.2.0/0-pre.2.fix.2.md

@@ -0,0 +1,43 @@
+<!-- file: deltas/0.2.0/0-pre.2.fix.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.2.fix.2
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.2.fix.1`.
+
+Le delta `0-pre.2.fix.1.md` reste immuable.
+
+## Objet
+
+Correction strictement documentaire des erreurs détectées par `scripts/audit_markdown_tables.py`.
+
+## Corrections
+
+- alignement vertical complet du tableau de `docs/studies/003-PLATFORM_CAPABILITY_STUDY.md` ;
+- conservation de l'alignement Markdown sémantique à gauche pour les colonnes textuelles ;
+- suppression d'une double ligne vide interdite dans `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md`.
+
+Aucun contenu fonctionnel ou architectural n'est ajouté ou modifié.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/studies/003-PLATFORM_CAPABILITY_STUDY.md` ;
+- `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md`.
+
+Les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 ou smoke n'est requise : ce fix ne touche ni code runtime ni configuration de build, hors métadonnées de version.

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

@@ -0,0 +1,53 @@
+<!-- file: deltas/0.2.0/0-pre.2.fix.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.2.fix.3
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.2.fix.2`.
+
+Les deltas précédents restent immuables.
+
+## Objet
+
+Corriger le format du tableau de plateformes selon la convention exacte déjà contrôlée par `scripts/audit_markdown_tables.py`, héritée des outils KSP.
+
+## Convention corrigée
+
+La convention est désormais documentée ainsi :
+
+- toutes les lignes de contenu ont une largeur brute identique par colonne ;
+- les cellules de contenu utilisent les espaces de padding nécessaires ;
+- la cellule de la ligne séparatrice ne contient aucun espace ;
+- elle est composée de tirets sur exactement toute la largeur brute de la colonne ;
+- les marqueurs `:` éventuels remplacent des tirets et ne changent jamais cette largeur.
+
+Exemple :
+
+```markdown
+| Colonne A | Colonne B      |
+|-----------|----------------|
+| valeur    | autre valeur   |
+```
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/rules/RULES_DOCUMENTATION.md` ;
+- `docs/studies/003-PLATFORM_CAPABILITY_STUDY.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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
+```
+
+Aucun contenu fonctionnel n'est ajouté dans ce fix.

deltas/0.2.0/0-pre.2.md

@@ -0,0 +1,65 @@
+<!-- file: deltas/0.2.0/0-pre.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.2
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.1.fix.2`.
+
+## Objet
+
+Étudier les fonctionnalités plausibles déjà justifiées et leur ownership architectural sans encore planifier les POC techniques ni le premier projet réel.
+
+## Contenu
+
+- enregistrement du jalon `0-pre.1.fix.2` validé dans `history/` ;
+- inventaire fonctionnel initial ;
+- distinction kernel / technical capability / game-system / platform adapter / provider / server service / tooling / game-specific ;
+- étude des axes OS, device, execution model, host et backend ;
+- pressure test par plusieurs archétypes de jeux ;
+- étude des dépendances et de la composition statique ;
+- conservation de macOS/iOS comme plateformes réservées ;
+- absence volontaire de création de nouvelles crates.
+
+## Hors scope
+
+Cette prerelease ne :
+
+- fige pas encore l'architecture normative ;
+- ne crée pas le manifest produit définitif ;
+- ne planifie pas encore le POC Tauri Android ;
+- ne planifie pas le premier jeu réel ;
+- n'implémente aucune capability ;
+- ne crée aucune nouvelle crate runtime.
+
+## Validation automatique
+
+```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 par le contenu fonctionnel de cette tranche : aucun code runtime ou build n'est modifié.
+
+## Validation humaine
+
+Relire en priorité :
+
+- `docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md` ;
+- `docs/studies/002-LAYERING_AND_OWNERSHIP_STUDY.md` ;
+- `docs/studies/003-PLATFORM_CAPABILITY_STUDY.md` ;
+- `docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md` ;
+- `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md`.
+
+La revue doit notamment signaler :
+
+- fonctionnalités manquantes ;
+- fonctionnalités sur-réservées ;
+- mauvais ownership ;
+- dépendances trop fortes ;
+- confusion entre capability et game-system ;
+- limites plateforme oubliées.
+
+Les décisions retenues seront seulement ensuite promues vers `docs/architecture/`.

deltas/0.2.0/0-pre.3.fix.1.md

@@ -0,0 +1,39 @@
+<!-- file: deltas/0.2.0/0-pre.3.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.3.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.3`.
+
+Le delta `0-pre.3.md` reste immuable.
+
+## Objet
+
+Correction strictement documentaire d'une double ligne vide interdite par `scripts/audit_markdown_tables.py`.
+
+## Correction
+
+- suppression de la double ligne vide dans `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md` ;
+- aucun ajout fonctionnel ou architectural.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 ou smoke n'est requise.

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.

deltas/0.2.0/0-pre.4.fix.1.md

@@ -0,0 +1,66 @@
+<!-- file: deltas/0.2.0/0-pre.4.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.4.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.4`.
+
+Le delta `0-pre.4.md` reste immuable.
+
+## Objet
+
+Recentrer tous les POC plateforme étudiés sur Snake comme jeu-sonde unique.
+
+Le prochain jeu réel pressenti étant un super Snake, cette correction permet aux POC de plateforme de préparer directement ses besoins plutôt que de répartir l'effort entre Reflex et Snake.
+
+## Décision d'étude
+
+Les nouveaux POC plateforme utilisent Snake :
+
+- Tauri Android + Snake ;
+- Web navigateur direct + Snake ;
+- Tauri Desktop + Snake ;
+- builder Android multi-ABI centré sur Snake ;
+- futurs POC Windows/macOS/iOS SDL avec Snake lorsque les environnements sont disponibles.
+
+Reflex reste une référence technique historique pour les briques Tauri/WASM déjà construites, mais n'est plus le jeu principal des futurs POC plateforme.
+
+## Raisons
+
+Snake exerce davantage de besoins utiles pour le futur jeu réel :
+
+- input continu ;
+- clavier/swipe/touch ;
+- grille ;
+- plusieurs entités ;
+- collision/obstacles ;
+- état de jeu plus long ;
+- resize/orientation ;
+- virtual controls éventuels ;
+- future extension multi-snake et multiplayer.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/studies/000-README.md` ;
+- `docs/studies/009-PLATFORM_POC_CANDIDATES.md` ;
+- `docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md` ;
+- `docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md` ;
+- `docs/studies/012-PLATFORM_POC_SEQUENCE.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 implémentation runtime n'est ajoutée.

deltas/0.2.0/0-pre.4.fix.2.md

@@ -0,0 +1,45 @@
+<!-- file: deltas/0.2.0/0-pre.4.fix.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.4.fix.2
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.4.fix.1`.
+
+Le delta `0-pre.4.fix.1.md` reste immuable.
+
+## Objet
+
+Correction strictement documentaire de l'alignement du tableau de `docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md`.
+
+## Correction
+
+Le tableau est reconstruit selon la convention contrôlée par `scripts/audit_markdown_tables.py` :
+
+- largeur brute constante pour chaque colonne ;
+- padding des lignes de contenu ;
+- ligne séparatrice sans espaces ;
+- nombre de tirets exactement égal à la largeur brute de chaque colonne.
+
+Aucun contenu fonctionnel ou architectural n'est modifié.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 ou smoke n'est requise.

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.

deltas/0.2.0/0-pre.5.fix.1.md

@@ -0,0 +1,103 @@
+<!-- file: deltas/0.2.0/0-pre.5.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.5.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.5`.
+
+Le delta `0-pre.5.md` reste immuable.
+
+## Objet
+
+Préciser la spécification fonctionnelle de Uroburas avant la phase de classification architecturale.
+
+## Contenu embarqué et téléchargé
+
+Le jeu peut embarquer les premières maps solo et leurs assets.
+
+Il doit également permettre le téléchargement et la mise à jour séparée de maps, skins, sons, textures/sprites, rulesets et autres assets.
+
+## Anatomie minimale
+
+Un serpent valide contient au minimum :
+
+1. tête ;
+2. cou ;
+3. une unité de corps ;
+4. queue.
+
+Seul le corps est extensible.
+
+Un effet de rétrécissement ne peut pas réduire un serpent sous quatre unités hors règle de mort explicite.
+
+## Sprites et rotations
+
+La spec précise :
+
+- réutilisation des sprites par rotation lorsque possible ;
+- variantes dédiées pour les virages gauche/droite du corps ;
+- contrat de skin compatible avec cette géométrie ;
+- éditeur Web de skins possible d'abord pour les administrateurs puis, ultérieurement, pour les utilisateurs avec contraintes/modération.
+
+## Première version réelle Uroburas
+
+La priorité fonctionnelle est désormais explicitement :
+
+1. Mode 1 — Challenge ;
+2. Mode 3 — Persistent Battle Royale ;
+3. Mode 2 — PvP Battles.
+
+La première version réelle se concentre sur les moteurs nécessaires au Mode 1 :
+
+- grille/tilemap toroïdale ;
+- obstacles ;
+- items ;
+- vies ;
+- temps ;
+- stages ;
+- caméra ;
+- contrôles ;
+- site Web ;
+- auth ;
+- rewarded ads ;
+- Hall of Fame initial ;
+- échange client/serveur authentifié/versionné/validable ;
+- téléchargement de contenu.
+
+## Contrôles Mobile/Tablet
+
+La première approche privilégie des boutons directionnels affichés à l'écran, équivalents fonctionnels des contrôles clavier Desktop, plutôt qu'un contrôle principal par swipe.
+
+## Rewarded ads
+
+Outre la continuation après perte de toutes les vies, une rewarded ad peut être proposée pendant la transition de stage pour appliquer un bonus volontaire, par exemple doubler les points gagnés sur le stage terminé.
+
+## Combat avancé
+
+Feu, glace, poison, téléporteurs et protections restent décrits comme direction fonctionnelle, mais sont explicitement hors scope de la première version réelle centrée sur le Mode 1.
+
+## Fichiers modifiés
+
+- `Cargo.toml` ;
+- `Android/game-reflex-poc/build.gradle` ;
+- `Android/game-snake-poc/build.gradle` ;
+- `README.md` ;
+- `docs/studies/013-UROBURAS_FUNCTIONAL_SPEC.md` ;
+- `docs/studies/014-UROBURAS_MODES_AND_SESSION_RULES.md` ;
+- `docs/studies/015-UROBURAS_MAP_ASSET_AND_UGC_SPEC.md` ;
+- `docs/studies/016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md` ;
+- `docs/studies/017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md`.
+
+Tous les fichiers existants modifiés et possédant un en-tête `version` ont été incrémentés.
+
+## 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 ou smoke n'est requise pour ce fix documentaire.

deltas/0.2.0/0-pre.5.md

@@ -0,0 +1,43 @@
+<!-- file: deltas/0.2.0/0-pre.5.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.5
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.4.fix.2`.
+
+## Objet
+
+Décrire fonctionnellement le prochain jeu réel, `Uroburas`, avant reclassification architecturale.
+
+## Contenu
+
+- client léger en contenu avec téléchargement de maps/assets ;
+- Challenge solo/offline-capable ;
+- PvP Battles authentifié avec maps, joueurs présélectionnés/aléatoires, équipes, bots et spectator ;
+- Persistent Battle Royale authentifié ;
+- règles spécialisables par map ;
+- armes/protections avec effets différents tête/corps/queue ;
+- score, vies, rewarded continue/rejoin ;
+- éditeur de maps, skins/UGC ;
+- Hall of Fame ;
+- replay/streaming/video régénérée côté serveur.
+
+## Règle de build
+
+Les scripts Python restent autorisés pour audit et validation complémentaire mais ne pilotent pas les builds. Les builds utilisent les outils natifs appropriés, notamment Cargo, Gradle et Tauri CLI. Builds, tests unitaires/intégration et smoke tests restent exécutés côté utilisateur.
+
+## Classification
+
+Le mapping vers engine, capability, game-system, Uroburas-specific, platform, provider, server et tooling est réservé à la prerelease suivante.
+
+## 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 cette prerelease documentaire.

deltas/0.2.0/0-pre.6.fix.1.md

@@ -0,0 +1,84 @@
+<!-- file: deltas/0.2.0/0-pre.6.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.6.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.6`.
+
+Le delta `0-pre.6.md` reste immuable.
+
+## Objet
+
+Compléter la classification de `0-pre.6` avec la stratégie réseau/asset delivery récente et formaliser la discipline de dimensionnement des versions/sessions inspirée du workflow KSP.
+
+## Workflow de version
+
+`0-pre.1` devient obligatoirement la tranche de cadrage :
+
+- audit de la base ;
+- brainstorming/recherche de requirements ;
+- sizing ;
+- planification ;
+- dépendances ;
+- validations ;
+- découpage prévisionnel.
+
+Une version doit être dimensionnée pour être entièrement terminée dans une seule session.
+
+Les tranches `pre/alpha/beta/rc` visent généralement des deltas de 15 à 30 minutes. Une tranche trop lourde est scindée avant exécution ; une tranche trop petite peut être regroupée avec une tranche cohérente.
+
+La dernière tranche avant publication consolide validations, documentation durable, CHANGELOG, ROADMAP et prompt suivant. La release stable reste autant que possible mécanique.
+
+## Réseau et asset delivery
+
+La direction étudiée devient :
+
+- Actix Web pour Web/API ;
+- asset delivery auto-hébergé ;
+- HTTP/2 baseline ;
+- HTTP/3/QUIC pour les assets lorsque disponible ;
+- H2/H3 sur un même hostname de préférence ;
+- séparation logique initiale, séparation physique progressive ;
+- WebSocket/tokio-tungstenite comme baseline realtime ;
+- WebTransport/QUIC comme candidat à benchmarker ;
+- fallback transport ;
+- simulation indépendante du transport ;
+- gRPC/Tonic réservé principalement aux frontières server-to-server justifiées.
+
+## Classification
+
+La capability réseau est décomposée conceptuellement en :
+
+```text
+HTTP client
+realtime transport API
+WebSocket implementation
+WebTransport implementation
+wire protocol
+session protocol
+reconnect/resync
+```
+
+Les crates Uroburas ne dépendent pas directement d'un transport concret.
+
+## Reste de la 0.2.0
+
+Après validation de cette tranche :
+
+1. consolider les études acceptées dans `docs/architecture/` et les règles durables ;
+2. réconcilier ROADMAP et décisions finales ;
+3. produire la tranche de clôture documentaire ;
+4. préparer le prompt de la session `0.3.x` consacrée aux POC ;
+5. passer en RC puis stable sans rouvrir le scope.
+
+## 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 ou smoke n'est requise : cette correction reste documentaire.

deltas/0.2.0/0-pre.6.md

@@ -0,0 +1,75 @@
+<!-- file: deltas/0.2.0/0-pre.6.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.6
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.5.fix.1`.
+
+## Objet
+
+Classifier les fonctionnalités Uroburas avant toute implémentation afin d'éviter un monolithe dans les futures crates multiplateformes du jeu.
+
+## Classification
+
+Les responsabilités sont réparties entre :
+
+- engine kernel ;
+- technical capabilities ;
+- game-systems réutilisables ;
+- gameplay Uroburas-specific ;
+- services serveur ;
+- providers ;
+- platform adapters ;
+- tooling.
+
+## Décomposition candidate
+
+L'étude propose des familles de crates pour :
+
+- capabilities ;
+- game-systems ;
+- Uroburas ;
+- apps ;
+- servers ;
+- providers ;
+- tools.
+
+Aucune création massive de crates n'est imposée : l'extraction doit rester motivée par une frontière et une API réelles.
+
+## Stack serveur de référence
+
+Direction étudiée :
+
+- Tokio ;
+- Actix Web ;
+- Maud ;
+- tokio-tungstenite pour le realtime public ;
+- tonic/gRPC conditionnel pour server-to-server ;
+- Fluent/fluent-bundle ;
+- Lettre.
+
+Le client public reste orienté `HTTPS + WebSocket`.
+
+## Ordre d'implémentation
+
+Priorité :
+
+1. fondations réutilisables ;
+2. game-systems du Mode 1 ;
+3. Uroburas Challenge ;
+4. services Web V1 ;
+5. intégration client/server Mode 1 ;
+6. Mode 3 ;
+7. Mode 2.
+
+## 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 : ce delta reste documentaire.

deltas/0.2.0/0-pre.7.md

@@ -0,0 +1,82 @@
+<!-- file: deltas/0.2.0/0-pre.7.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.7
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.6.fix.1`.
+
+Cette base est utilisée comme état de travail. Aucune entrée d'historique ne prétend que `0-pre.6.fix.1` a déjà passé une validation utilisateur non fournie.
+
+## Objet
+
+Promouvoir les décisions retenues des études `0.2.0` vers des documents durables d'architecture et de règles.
+
+## Architecture consolidée
+
+Documents ajoutés :
+
+- architecture modulaire et ownership ;
+- architecture réseau/serveur ;
+- architecture cible Uroburas ;
+- architecture des POC plateforme/réseau.
+
+Les études restent comme justification et historique de conception ; les nouveaux documents portent les orientations durables.
+
+## Règles consolidées
+
+Deux règles durables sont ajoutées :
+
+- cadrage des versions/sessions/prompts ;
+- portabilité et auto-hébergement serveur.
+
+La cible opérationnelle préférée est Debian Stable, actuellement Debian 13 `trixie`, sans dépendance métier à cette version.
+
+Les choix futurs HAProxy/nginx/HTTP3 edge/storage restent explicitement hors gel `0.2.0`.
+
+## Réseau durable
+
+- Actix Web reste la référence Web/API ;
+- Maud reste la référence HTML server-side ;
+- Fluent/fluent-bundle porte la localisation ;
+- Lettre porte l'email transactionnel ;
+- WebSocket/tokio-tungstenite est la baseline realtime ;
+- WebTransport/QUIC reste un candidat POC ;
+- gRPC/Tonic est conditionnel aux frontières server-to-server ;
+- asset delivery reste auto-hébergé et compatible H2/H3 selon disponibilité.
+
+## Workflow durable
+
+`pre.1` devient la tranche obligatoire de cadrage.
+
+Une version est dimensionnée pour tenir dans une session.
+
+Les tranches visent normalement 15 à 30 minutes et restent fonctionnellement complètes.
+
+La fin de version consolide CHANGELOG, ROADMAP et le prompt suivant ; la stable reste mécanique.
+
+## ROADMAP
+
+Les lignes de scope `0.2.0` ne sont pas marquées comme complètes dans ce delta avant revue humaine de la consolidation.
+
+## Suite attendue
+
+Après validation de `0-pre.7` :
+
+1. audit documentaire global ;
+2. réconciliation finale studies/architecture/rules/ROADMAP ;
+3. CHANGELOG de candidate ;
+4. prompt de session `0.3.x` ;
+5. RC documentaire ;
+6. release stable mécanique.
+
+## 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 : `0.2.0` reste strictement documentaire hors métadonnées de version.

deltas/0.2.0/0-pre.8.fix.1.md

@@ -0,0 +1,40 @@
+<!-- file: deltas/0.2.0/0-pre.8.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.8.fix.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.8`.
+
+Le delta `0-pre.8.md` reste immuable.
+
+## Objet
+
+Renforcer le prompt de démarrage `0.3.x` afin qu'il fournisse un véritable plan de session exploitable, inspiré du modèle KSP mais plus compact.
+
+## Correction
+
+Le prompt ajoute :
+
+- mission bornée de `0.3.0` ;
+- cadrage `0-pre.1` détaillé ;
+- forecast souple tranche par tranche pour `0.3.0` ;
+- objectifs et critères des phases pre/alpha/beta/rc candidates ;
+- règles de fusion/scission/report ;
+- forecast initial `0.3.0` à `0.3.6` ;
+- dépendances entre versions ;
+- ordre de préférence des premiers POC ;
+- critères de fin explicites.
+
+Le forecast n'est pas contractuel : `pre.1` doit le corriger immédiatement si le sizing réel le contredit.
+
+## 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 : ce fix est documentaire hors métadonnées de version.

deltas/0.2.0/0-pre.8.md

@@ -0,0 +1,58 @@
+<!-- file: deltas/0.2.0/0-pre.8.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-0-pre.8
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.7`.
+
+`0-pre.7` a été validée par revue humaine et audits projet.
+
+## Objet
+
+Clore la phase de conception `0.2.0` avant RC.
+
+## Réconciliation finale
+
+Cette tranche :
+
+- ferme les lignes durables `0.2.0` du ROADMAP ;
+- ajoute le résumé `CHANGELOG` de `0.2.0` ;
+- ajoute une baseline architecturale consolidée ;
+- enregistre l'historique validé de `0-pre.7` ;
+- prépare le prompt de session `0.3.x`.
+
+## Prompt 0.3.x
+
+Le prompt fixe :
+
+- `pre.1` comme cadrage obligatoire ;
+- Snake comme jeu-sonde ;
+- POC Tauri Android/Web/Tauri Desktop/Android multi-ABI ;
+- POC WebSocket vs WebTransport/QUIC ;
+- builds via outils natifs ;
+- utilisateur responsable des builds/tests/smoke ;
+- Debian Stable comme cible opérationnelle préférée ;
+- Uroburas réservé à `0.4.x`.
+
+## Gel
+
+Après validation de `0-pre.8`, le scope documentaire `0.2.0` est considéré complet.
+
+La RC suivante est une candidate de publication :
+
+- aucune nouvelle fonctionnalité ;
+- aucune nouvelle orientation architecturale ;
+- corrections seulement si nécessaires ;
+- revue humaine finale.
+
+## 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 ou smoke n'est requise : `0.2.0` reste documentaire hors métadonnées de version.

deltas/0.2.0/3-rc.1.md

@@ -0,0 +1,46 @@
+<!-- file: deltas/0.2.0/3-rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0-3-rc.1
+
+## Base
+
+Base déclarée : `0.2.0-0-pre.8.fix.1`.
+
+Cette base a été validée par revue humaine et audits projet.
+
+## Objet
+
+Créer la candidate de publication `0.2.0`.
+
+## Gel
+
+Le scope `0.2.0` est gelé.
+
+Cette RC n'ajoute :
+
+- aucune nouvelle fonctionnalité ;
+- aucune nouvelle orientation architecturale ;
+- aucune nouvelle capability ;
+- aucun nouveau POC.
+
+Elle consolide uniquement :
+
+- métadonnées de version ;
+- CHANGELOG RC ;
+- historique de la dernière prerelease validée ;
+- checklist de revue RC.
+
+## 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 ou smoke n'est requise : la version reste documentaire hors métadonnées.
+
+## Après validation
+
+Si cette RC est validée sans correction sémantique, la release `0.2.0` doit être mécanique.

deltas/0.2.0/rel.001.md

@@ -0,0 +1,42 @@
+<!-- file: deltas/0.2.0/rel.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.2.0 — release stable
+
+## Base
+
+Base validée : `0.2.0-3-rc.1`.
+
+## Objet
+
+Promouvoir mécaniquement la candidate validée vers `0.2.0`.
+
+## Changements
+
+La release stable modifie uniquement :
+
+- la version workspace ;
+- les métadonnées Android correspondantes ;
+- la version affichée dans le README ;
+- l'en-tête CHANGELOG de candidate vers stable ;
+- l'historique de validation de la RC.
+
+Aucun nouveau scope fonctionnel, architectural ou documentaire n'est introduit.
+
+## 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 ou smoke supplémentaire n'est requise pour cette promotion documentaire/métadonnée.
+
+## Publication
+
+Après validation :
+
+- commit de release ;
+- tag stable `v0.2.0` ;
+- ouverture de la session `0.3.0` à partir de `prompts/002-V0_3_X_START_PROMPT.md`.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 18 -->
+<!-- version: 21 -->
 
 # Documentation games.sasedev
 
@@ -7,6 +7,11 @@
 
 - [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md) — finalité, principes structurants, stratégie de construction et vision du SDK.
 
+## Idées et études
+
+- [`ideas/000-README.md`](ideas/000-README.md) — rôle des idées non engagées et règles de maturation.
+- [`studies/000-README.md`](studies/000-README.md) — rôle des études comparatives non normatives.
+
 ## Architecture
 
 - [`architecture/001-WORKSPACE_ARCHITECTURE.md`](architecture/001-WORKSPACE_ARCHITECTURE.md) — workspace, générations de moteur, jeux, runners, assets et Android.
@@ -17,6 +22,12 @@
 - [`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.
+- [`architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md`](architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md) — architecture durable kernel/capabilities/game-systems/games/adapters/providers/services/tooling.
+- [`architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md`](architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md) — Web/API, realtime, transports, asset delivery auto-hébergé et frontières serveur.
+- [`architecture/014-UROBURAS_TARGET_ARCHITECTURE.md`](architecture/014-UROBURAS_TARGET_ARCHITECTURE.md) — ownership cible des besoins Uroburas et ordre Mode 1 → Mode 3 → Mode 2.
+- [`architecture/015-PLATFORM_POC_ARCHITECTURE.md`](architecture/015-PLATFORM_POC_ARCHITECTURE.md) — rôle des POC `0.3.x`, Snake comme sonde et critères d'extraction.
+- [`architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md`](architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md) — synthèse de la baseline destinée au gel RC `0.2.0`.
+- [`architecture/017-V0_2_0_RC_REVIEW.md`](architecture/017-V0_2_0_RC_REVIEW.md) — checklist de cohérence et scope gelé de la candidate `0.2.0-3-rc.1`.
 
 ## Jeux
 
@@ -40,7 +51,7 @@
 
 ## Règles
 
-Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution des commandes.
+Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_DOCUMENTATION.md`](rules/RULES_DOCUMENTATION.md) pour la gouvernance documentaire, [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution, [`rules/RULES_VALIDATION_MATRIX.md`](rules/RULES_VALIDATION_MATRIX.md) pour la matrice des gates, [`rules/RULES_SESSION_PLANNING.md`](rules/RULES_SESSION_PLANNING.md) pour le cadrage des sessions et [`rules/RULES_SERVER_HOSTING.md`](rules/RULES_SERVER_HOSTING.md) pour la portabilité d'auto-hébergement.
 
 ## Validation
 
@@ -60,4 +71,4 @@ Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_COMMANDS.md`](rules/R
 
 ## Historique validé
 
-- [`../history/README.md`](../history/README.md) — convention et navigation de l'historique transitoire immuable des jalons validés.
+- [`../history/000-README.md`](../history/000-README.md) — convention et navigation de l'historique transitoire immuable des jalons validés.

docs/architecture/003-SDL3_PLATFORM_ABSTRACTION.md

@@ -15,17 +15,26 @@ Engine API
 SDL3 boundary
  ┌───┼───────────────┐
  │   │               │
-Desktop           Android            Web
-native            SDL/JNI            WASM/browser
+Desktop           Mobile             Web
+SDL native        SDL/native         WASM/browser
+ │                 │
+Linux/Windows/     Android/iOS
+macOS
 ```
 
 ## Desktop
 
+La famille Desktop réserve Linux, Windows et macOS. Leur support effectif dépend des backends, bibliothèques et contraintes de distribution disponibles au moment de l'implémentation.
+
 Le runner Desktop est la cible d'itération la plus rapide. Il utilise la crate lib du jeu et, à terme, le runtime SDL3 natif. Les entrées disponibles peuvent inclure clavier, souris, trackpad, gamepad et joystick.
 
 La cible Desktop sert à tester le gameplay, le rendu, la boucle de jeu, l'audio et les abstractions communes sans imposer un déploiement sur émulateur ou téléphone.
 
-## Android
+## Mobile
+
+La famille Mobile réserve Android et iOS. Téléphone et tablette sont des classes de device et ne doivent pas être confondus avec l'OS ou le backend de rendu.
+
+### Android
 
 Android empaquette le jeu natif dans une application standard. La structure cible combine : SDL3 Android, une bibliothèque native Rust, la couche Java commune, les extensions Java spécifiques au jeu, les assets communs et spécifiques, puis les SDK Android requis.
 
@@ -33,6 +42,10 @@ Les fonctionnalités suivantes restent côté plateforme Android : lifecycle, JN
 
 Le gameplay Rust ne doit pas dépendre des classes Java ni d'une régie publicitaire particulière.
 
+### iOS
+
+iOS est une cible réservée pour une évolution future. Aucun support de distribution iOS n'est exigé dans le POC actuel. L'architecture ne doit toutefois pas introduire une dépendance structurelle qui rendrait impossible un backend SDL/native ou un adapter iOS ultérieur.
+
 ## Web / WASM
 
 La cible Web est prévue comme cible ultérieure. SDL3 peut être utilisé avec une chaîne Web adaptée, notamment Emscripten, tandis que le navigateur fournit ses propres contraintes de boucle d'événements, audio, stockage, permissions et interaction utilisateur.

docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md

@@ -0,0 +1,56 @@
+<!-- file: docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md -->
+<!-- version: 1 -->
+
+# Architecture modulaire et ownership
+
+## Décision
+
+Le framework est structuré par responsabilité et non par jeu ou plateforme unique.
+
+```text
+game-specific
+    ↓
+game-systems
+    ↓
+technical capabilities
+    ↓
+engine kernel contracts
+```
+
+La composition produit ajoute latéralement les platform adapters, providers, server contracts et tooling.
+
+## Engine kernel
+
+Le kernel contient uniquement les primitives nécessaires à tous les jeux consommateurs : lifecycle, update/render, temps, runtime events, provenance et contrats minimaux input/render.
+
+Il ne contient pas de logique Snake, publicité, authentification, HTTP ou règles Uroburas.
+
+## Technical capabilities
+
+Les capabilities fournissent des mécanismes techniques réutilisables : input, rendu 2D, audio, assets/content, localisation, persistence, networking et logging/telemetry.
+
+## Game-systems
+
+Les game-systems portent des mécaniques réutilisables entre jeux lorsque leur API est réellement justifiée : grid/tilemap, collision, caméra gameplay, stages, score, vies/attempts, timed entities, pickups/inventory et status effects lorsque leur généralisation devient réelle.
+
+## Game-specific
+
+Une crate jeu conserve les règles propres au jeu, la composition des systèmes et les concepts qui n'ont pas encore de second consommateur crédible.
+
+Une mécanique n'est pas extraite uniquement parce qu'elle pourrait théoriquement servir ailleurs.
+
+## Adapters, providers et services
+
+Les adapters traduisent un environnement local. Les providers encapsulent un service externe. Le gameplay ne dépend pas directement d'un adapter ou SDK provider concret.
+
+Les services serveur possèdent leurs modèles métier et leurs contrats de transport dédiés. Actix, Tungstenite, Protobuf ou Maud ne remontent pas dans le gameplay.
+
+## Tooling
+
+Éditeurs, build tooling, audits et outils de publication restent séparés du runtime du jeu.
+
+## Création de crates
+
+Une nouvelle crate est justifiée par une frontière stable ou un besoin de réutilisation réel.
+
+Le projet évite à la fois la crate jeu monolithique et l'explosion artificielle en une crate par concept minuscule.

docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md

@@ -0,0 +1,85 @@
+<!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture réseau et serveur
+
+## Web/API
+
+La stack serveur Web de référence est :
+
+```text
+Tokio
+Actix Web
+Maud
+Fluent / fluent-bundle
+Lettre
+```
+
+Actix Web porte le Web/API, l'authentification, les comptes, Hall of Fame, metadata de contenu, reward authority et administration initiale.
+
+## Realtime
+
+Le realtime est séparé du Web/API classique.
+
+Baseline :
+
+```text
+Tokio
+tokio-tungstenite
+WebSocket
+```
+
+Candidat à évaluer :
+
+```text
+WebTransport
+QUIC
+```
+
+La simulation authoritative ne dépend directement d'aucun de ces transports.
+
+## Frontière de transport
+
+```text
+transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+synchronization
+    ↓
+authoritative simulation
+```
+
+Le client utilise une realtime transport API. WebSocket reste le fallback de référence. WebTransport est évalué lorsqu'il apporte un bénéfice mesuré.
+
+## gRPC
+
+`tonic`/gRPC est réservé aux frontières server-to-server qui le justifient. Il n'est pas un transport obligatoire entre le client public et le serveur realtime.
+
+## Asset delivery
+
+Les assets sont auto-hébergés par défaut.
+
+```text
+assets.games.sasedev.com
+    HTTP/2
+    HTTP/3/QUIC si disponible
+```
+
+H2 et H3 peuvent coexister sur le même hostname avec fallback.
+
+Content metadata/authorization et transfert lourd d'assets sont deux responsabilités distinctes.
+
+## Déploiement progressif
+
+Une seule machine peut initialement héberger plusieurs services logiques.
+
+L'architecture permet ensuite de séparer Web/API, Assets, Realtime, Database et Media/replay, puis de multiplier les nœuds selon la charge.
+
+## Portabilité d'exploitation
+
+Debian Stable est la cible opérationnelle préférée.
+
+Le choix futur d'un edge/reverse proxy HTTP/3, stockage ou composant d'infrastructure reste reporté aux POC correspondants et doit tenir compte de la disponibilité/maturité sur Debian Stable.

docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md

@@ -0,0 +1,74 @@
+<!-- file: docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture cible Uroburas
+
+## Principe
+
+Uroburas n'est pas une crate monolithique.
+
+La crate jeu conserve ce qui décrit réellement Uroburas ; les mécanismes réutilisables, services serveur, intégrations provider et tooling vivent dans leurs couches respectives.
+
+## Première trajectoire
+
+```text
+Mode 1 — Challenge
+    ↓
+Mode 3 — Persistent Battle Royale
+    ↓
+Mode 2 — PvP Battles
+```
+
+La première version réelle stabilise d'abord les moteurs du Mode 1.
+
+## Réutilisable hors Uroburas
+
+À implémenter comme capabilities ou game-systems lorsque les frontières sont suffisamment claires :
+
+- input abstrait ;
+- virtual directional controls ;
+- rendu sprite/rotation ;
+- grid/tilemap toroïdale ;
+- collision ;
+- caméra ;
+- stages ;
+- vies/attempts ;
+- score ;
+- timed entities ;
+- pickups ;
+- assets/content download/cache ;
+- localisation Fluent ;
+- networking client.
+
+## Uroburas-specific
+
+Reste spécifique au jeu au départ :
+
+- anatomie tête + cou + corps extensible + queue ;
+- longueur minimale de quatre unités ;
+- mouvement Snake ;
+- géométrie du corps ;
+- règles propres aux maps Uroburas ;
+- règles de run Challenge ;
+- modes Uroburas ;
+- combat feu/glace/poison/protections/téléporteurs tant qu'aucun second jeu ne justifie leur généralisation.
+
+## Serveur Mode 1
+
+La première trajectoire serveur couvre PlayerId/auth, comptes, map/asset metadata, contenu téléchargeable, Hall of Fame, rewarded continue, rewarded stage multiplier, validation/idempotence et échanges HTTP sécurisés/versionnés.
+
+Le realtime n'est pas requis pour le Mode 1.
+
+## Mode 3 puis Mode 2
+
+Le Mode 3 introduit authoritative simulation, realtime transport, bots, spectator, snapshots/deltas, interest management, rejoin cooldown et persistent world lifecycle.
+
+Le Mode 2 réutilise ensuite ces briques pour les matches bornés, privés, matchmaking, équipes et règles de vie.
+
+## Tooling
+
+Le map editor démarre lorsque le format de map est suffisamment stable.
+
+Le skin editor vient après stabilisation du contrat graphique des skins.
+
+Ils restent séparés du runtime du jeu.

docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md

@@ -0,0 +1,45 @@
+<!-- file: docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# Architecture des POC plateforme et réseau
+
+## Rôle de la série 0.3.x
+
+La série `0.3.x` doit éprouver les frontières décidées en `0.2.0` avant le développement Uroburas réel.
+
+Snake est le jeu-sonde principal.
+
+## POC plateforme prioritaires
+
+Première vague :
+
+- Tauri Android + Snake ;
+- Web navigateur direct + Snake ;
+- Tauri Desktop + Snake ;
+- build Android multi-ABI avec outils natifs.
+
+Plateformes supplémentaires lorsque l'environnement existe : Windows SDL natif, macOS SDL natif et iOS SDL natif.
+
+## POC réseau
+
+Avant le Mode 3, comparer au minimum WebSocket/tokio-tungstenite, WebTransport/QUIC, fallback automatique, charge, reconnect/resync, backpressure, snapshots/deltas et mobilité réseau.
+
+Le même protocole métier doit pouvoir être exercé sur plusieurs transports.
+
+## Build
+
+Les builds utilisent Cargo, Gradle, Tauri CLI et les toolchains plateforme.
+
+Python reste limité aux audits, validations complémentaires et contrôles statiques.
+
+## Critère d'extraction
+
+Un POC sert à identifier duplication, adapters manquants, capability réellement réutilisable, frontières mal placées et coût de maintenance.
+
+Une abstraction n'est pas extraite avant observation d'un besoin concret.
+
+## Relation avec Uroburas
+
+Les résultats des POC `0.3.x` déterminent les choix techniques conservés pour la trajectoire Uroburas `0.4.x`.
+
+Le POC ne doit pas réimplémenter le futur jeu ; il valide ses fondations.

docs/architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md

@@ -0,0 +1,70 @@
+<!-- file: docs/architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md -->
+<!-- version: 1 -->
+
+# Baseline architecturale consolidée 0.2.0
+
+## Statut
+
+Ce document synthétise la baseline documentaire destinée à être gelée par la RC `0.2.0`.
+
+## Framework
+
+Le projet retient une architecture modulaire distinguant :
+
+- engine kernel ;
+- technical capabilities ;
+- game-systems ;
+- game-specific ;
+- platform adapters ;
+- providers ;
+- server services ;
+- tooling.
+
+## POC
+
+La série `0.3.x` valide les choix plateforme/réseau avec Snake comme jeu-sonde.
+
+## Uroburas
+
+La série `0.4.x` démarre le jeu réel Uroburas, d'abord Mode 1 Challenge.
+
+Ordre produit actuel :
+
+```text
+Mode 1
+→ Mode 3
+→ Mode 2
+```
+
+## Réseau
+
+- Actix Web pour Web/API ;
+- Maud pour HTML server-side ;
+- Fluent pour i18n ;
+- Lettre pour email ;
+- WebSocket/tokio-tungstenite baseline realtime ;
+- WebTransport/QUIC candidat POC ;
+- gRPC/Tonic conditionnel server-to-server ;
+- asset delivery auto-hébergé H2/H3 selon disponibilité.
+
+## Exploitation
+
+Debian Stable est la cible opérationnelle préférée.
+
+Le code métier reste indépendant de la version de distribution.
+
+Les composants d'infrastructure spécifiques restent hors du domaine et seront choisis lors de POC/déploiements dédiés.
+
+## Workflow
+
+- `pre.1` cadre chaque version ;
+- une version tient dans une session ;
+- les tranches visent généralement 15–30 minutes ;
+- les dernières tranches consolident documentation, ROADMAP, CHANGELOG et prompt suivant ;
+- la stable reste mécanique.
+
+## Gel
+
+La RC suivante ne doit plus ajouter de nouveau scope.
+
+Toute découverte fonctionnelle majeure après gel est reportée vers `0.3.x`, `0.4.x` ou une version ultérieure selon sa nature.

docs/architecture/017-V0_2_0_RC_REVIEW.md

@@ -0,0 +1,58 @@
+<!-- file: docs/architecture/017-V0_2_0_RC_REVIEW.md -->
+<!-- version: 1 -->
+
+# Revue RC 0.2.0
+
+## Statut
+
+Candidate `0.2.0-3-rc.1`.
+
+Le scope fonctionnel et architectural de `0.2.0` est gelé.
+
+## Cohérence documentaire
+
+La candidate relie :
+
+- études exploratoires ;
+- architecture durable ;
+- règles normatives ;
+- ROADMAP ;
+- CHANGELOG ;
+- prompt `0.3.x`.
+
+Les études restent la justification historique ; les documents d'architecture et de règles portent les décisions durables.
+
+## Décisions gelées
+
+- architecture kernel / capabilities / game-systems / game-specific ;
+- séparation adapters/providers/apps ;
+- Snake comme sonde `0.3.x` ;
+- Uroburas comme trajectoire `0.4.x` ;
+- ordre Uroburas Mode 1 → Mode 3 → Mode 2 ;
+- Actix Web / Maud / Fluent / Lettre comme références Web ;
+- WebSocket/tokio-tungstenite baseline realtime ;
+- WebTransport/QUIC candidat POC ;
+- gRPC/Tonic conditionnel server-to-server ;
+- asset delivery auto-hébergé, H2 baseline et H3 candidat ;
+- Debian Stable comme cible opérationnelle préférée ;
+- `pre.1` obligatoire de cadrage ;
+- versions dimensionnées pour une session ;
+- tranches visant généralement 15 à 30 minutes ;
+- stable mécanique.
+
+## Hors gel
+
+Restent volontairement à valider plus tard par POC :
+
+- ordre exact des versions `0.3.x` après `0.3.0` ;
+- choix définitif WebSocket vs WebTransport ;
+- choix edge/reverse proxy H3 ;
+- détails de packaging/infrastructure par plateforme ;
+- abstractions réellement extraites après observation de duplication ;
+- décisions techniques propres à Uroburas au-delà du Mode 1 initial.
+
+## Critère de publication
+
+Si les audits RC sont propres et qu'aucune incohérence documentaire n'est détectée, `0.2.0` stable doit être une promotion mécanique de cette candidate.
+
+Aucun nouveau scope ne doit être ajouté entre RC et stable.

docs/ideas/000-README.md

@@ -0,0 +1,22 @@
+<!-- file: docs/ideas/000-README.md -->
+<!-- version: 1 -->
+
+# Idées
+
+Ce répertoire accueille les idées, variantes et possibilités qui méritent d'être conservées sans devenir automatiquement des engagements du projet.
+
+Une entrée ici peut concerner un jeu, une mécanique, une plateforme, un provider, un service ou un outil.
+
+Sa présence signifie uniquement :
+
+> idée identifiée et conservée pour discussion future.
+
+Elle ne signifie pas :
+
+- capability réservée ;
+- architecture retenue ;
+- fonctionnalité planifiée ;
+- crate à créer ;
+- engagement de version.
+
+Lorsqu'une idée nécessite une analyse structurée, elle peut donner naissance à une étude sous `docs/studies/`. Le document d'idée peut alors référencer cette étude sans être supprimé afin de conserver son origine.

docs/rules/FILE_CONTRACTS.md

@@ -1,15 +1,17 @@
 <!-- file: docs/rules/FILE_CONTRACTS.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Contrats des fichiers principaux
 
 - `README.md` présente le dépôt et ses entrées principales.
 - `RULES.md` indexe les règles normatives.
-- `ROADMAP.md` suit les objectifs futurs et leur état.
-- `CHANGELOG.md` conserve l'historique synthétique inversement chronologique.
+- `ROADMAP.md` conserve le planning durable et son historique de scope via `( )`, `(x)`, `(d)` et `(c)`.
+- `CHANGELOG.md` conserve une synthèse inversement chronologique à partir des jalons RC et stables.
 - `docs/000-README.md` indexe la documentation détaillée.
 - `docs/rules/` contient les règles durables.
-- `docs/architecture/` contient les décisions et descriptions d'architecture.
+- `docs/ideas/000-README.md` est le point d'entrée des idées et variantes non engagées.
+- `docs/studies/000-README.md` est le point d'entrée des analyses comparatives non normatives préparant une décision.
+- `docs/architecture/` contient les décisions et descriptions d'architecture retenues.
 - `docs/objectives/` décrit les objectifs et la stratégie produit/technique.
 - `docs/games/` classe les familles de jeux, leurs contrôles et leurs évolutions.
 - `docs/engine/` décrit l’évolution fonctionnelle des générations de moteur.
@@ -32,3 +34,18 @@
 - `crates/apps/<game>-tauri/src/tauri.rs` assemble Tauri et porte le pont Web/Rust.
 - `crates/apps/<game>-wasm/` contient l'adaptation WebAssembly distincte.
 - Les bindings JavaScript et modules `.wasm` générés restent ignorés par Git.
+
+## Points d'entrée documentaires
+
+- Le `README.md` racine du dépôt conserve son nom.
+- Un README propre à une crate, un package ou un répertoire technique peut conserver `README.md` lorsque cet usage est naturel à son écosystème.
+- Un répertoire documentaire conçu pour accumuler plusieurs fichiers Markdown utilise `000-README.md` comme point d'entrée.
+- `history/000-README.md` est le point d'entrée de l'historique validé.
+
+## Immutabilité et suppressions dans les deltas
+
+- Les fichiers `deltas/**/*.md` livrés sont immuables sur le fond.
+- Une correction de forme sans changement de sens peut modifier un delta existant uniquement en incrémentant son en-tête `version`.
+- Toute correction sémantique ou tout ajout produit un nouveau delta ou `.fix.N`.
+- Les fichiers `deltas/**/*.delete.txt` sont des manifests de suppression contractuels.
+- Chaque manifest contient un chemin relatif par ligne et est expliqué dans le fichier Markdown du delta qui l'introduit.

docs/rules/RULES_COMMANDS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_COMMANDS.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Règles d'exécution des commandes
 
@@ -29,8 +29,11 @@
 - **CMD-RUST-008** — `cargo build` est utilisé lorsqu'un artefact exécutable ou une bibliothèque est réellement nécessaire ; il n'est pas lancé systématiquement en plus de `cargo check`.
 - **CMD-RUST-009** — `cargo tree` et ses variantes sont des commandes de diagnostic de dépendances, pas des gates obligatoires de chaque delta.
 - **CMD-RUST-010** — `cargo update` n'est jamais exécuté opportunistement. Toute mise à jour de dépendance doit appartenir à une tranche explicitement consacrée aux dépendances ou être nécessaire à la fonctionnalité en cours.
-- **CMD-RUST-011** — `cargo clean` n'est pas une gate et n'est pas utilisé en routine. Il n'est autorisé qu'en cas de diagnostic de build corrompu, de contrainte disque explicite ou de demande ciblée, avec justification.
-- **CMD-RUST-012** — La suppression manuelle de `target/` ne remplace pas `cargo clean` et suit les mêmes restrictions.
+- **CMD-RUST-011** — `cargo clean` est l'outil canonique de remise à zéro complète du cache de build Cargo et peut être utilisé périodiquement pour maîtriser la taille de `../builds/sasedev-games/target`.
+- **CMD-RUST-012** — Un nettoyage complet n'est pas exécuté à chaque delta. Il est planifié à un jalon de cycle approprié, normalement au démarrage de la première prerelease de développement lorsque l'ancien cache doit être évacué, ou au plus tard avant la validation finale RC/stable si l'accumulation disque le justifie.
+- **CMD-RUST-013** — Entre deux nettoyages complets, les variantes ciblées de `cargo clean` (`-p`, `--release`, `--profile`, `--target`) sont préférées lorsqu'elles répondent au besoin de libération d'espace sans supprimer tout le cache.
+- **CMD-RUST-014** — `cargo clean --dry-run --verbose` peut être utilisé pour estimer l'impact d'un nettoyage avant suppression.
+- **CMD-RUST-015** — La suppression manuelle de `target/` ne remplace pas `cargo clean` et n'est utilisée qu'en diagnostic exceptionnel.
 
 ## Runners Desktop
 
@@ -46,7 +49,7 @@
 - **CMD-ANDROID-001** — Les commandes Gradle Android sont exécutées depuis `Android/` ou avec un chemin explicite vers le wrapper du projet.
 - **CMD-ANDROID-002** — Les tâches ciblées par application sont préférées, par exemple `./gradlew :game-reflex-poc:assembleDebug`, lorsqu'elles existent.
 - **CMD-ANDROID-003** — Un build Android global n'est pas exécuté si la tranche ne touche ni Android ni le contrat natif utilisé par Android.
-- **CMD-ANDROID-004** — `gradle clean` ou `./gradlew clean` n'est pas une gate normale et suit la même politique restrictive que `cargo clean`.
+- **CMD-ANDROID-004** — `gradle clean` ou `./gradlew clean` reste un nettoyage Android ciblé ; il n'est pas rendu obligatoire uniquement parce qu'un `cargo clean` est planifié.
 - **CMD-ANDROID-005** — Les commandes Android réelles ne deviennent des gates qu'après introduction du wrapper Gradle, de l'AGP, du NDK, de SDL3 et des modules exécutables correspondants.
 
 ## Web
@@ -67,7 +70,7 @@
 
 - **CMD-BETA-001** — À l'entrée en beta, `scripts/audit_distribution_layout.py` vérifie les frontières statiques nécessaires aux runners et packagings supportés.
 - **CMD-BETA-002** — La transition alpha vers beta exécute une suite Cargo workspace complète en plus des tests ciblés.
-- **CMD-BETA-003** — Le build Tauri de packaging est lancé via `cargo tauri build`; ses hooks possèdent le build WASM et Vite/TypeScript.
+- **CMD-BETA-003** — Si la version touche le périmètre Tauri, au moins un build de packaging beta est lancé via `cargo tauri build`; ses hooks possèdent le build WASM et Vite/TypeScript.
 - **CMD-BETA-004** — Les APK Debug servent à la validation multi-appareils beta ; la signature de publication appartient à la phase RC/stable.
 
 ## RC et release
@@ -79,3 +82,17 @@
 - **CMD-RC-005** — Android RC revalide au minimum x86_64 sur AVD et ARM64 sur appareil réel avec les APK issus de l'état RC.
 - **CMD-RC-006** — Les secrets de signature, keystores et credentials de publication ne sont jamais commités. Leur présence est une condition externe de publication, pas une donnée du dépôt.
 - **CMD-RC-007** — Une RC n'est promue en stable que si aucun correctif `.fix.N` n'est nécessaire après la gate RC complète.
+
+## Matrice de validation
+
+- **CMD-MATRIX-001** — `docs/rules/RULES_VALIDATION_MATRIX.md` associe des identifiants stables aux commandes et décrit leurs dépendances.
+- **CMD-MATRIX-002** — Lorsqu'une modification affecte une crate dont dépendent d'autres crates, les validations ciblées couvrent la crate modifiée et les consommateurs directement ou transitivement impactés selon la portée de l'API.
+- **CMD-MATRIX-003** — La matrice évolue avec le workspace ; ajouter une nouvelle plateforme ou un nouveau type de build doit ajouter ou adapter les commandes concernées plutôt que créer une procédure informelle parallèle.
+
+## Outils de build et scripts d'audit
+
+- **CMD-BUILD-001** — Les scripts Python du dépôt sont autorisés pour les audits, audits complémentaires, validations et validations complémentaires.
+- **CMD-BUILD-002** — Un script Python ne pilote pas le build d'un produit, d'une plateforme ou d'un package distribué.
+- **CMD-BUILD-003** — Les builds utilisent l'outil natif approprié au périmètre : Cargo pour Rust, Gradle pour Android, Tauri CLI pour Tauri, ou l'outil officiellement retenu par la plateforme concernée.
+- **CMD-BUILD-004** — Les POC `0.3.x` doivent remplacer toute orchestration de build Python restante par des procédures explicites, reproductibles et testées avec les outils natifs.
+- **CMD-BUILD-005** — Les builds, tests unitaires, tests d'intégration et smoke tests de validation sont exécutés côté utilisateur ; les scripts d'audit peuvent vérifier statiquement leur préparation mais ne les simulent pas.

docs/rules/RULES_DOCUMENTATION.md

@@ -1,8 +1,10 @@
 <!-- file: docs/rules/RULES_DOCUMENTATION.md -->
-<!-- version: 2 -->
+<!-- version: 6 -->
 
 # Règles de documentation
 
+## Principes généraux
+
 - **DOC-001** — La documentation structurée réside sous `docs/`.
 - **DOC-002** — `docs/000-README.md` est l'entrée de navigation documentaire.
 - **DOC-003** — Les documents normatifs résident sous `docs/rules/`.
@@ -10,12 +12,104 @@
 - **DOC-005** — Les documents de validation résident sous `docs/validation/`.
 - **DOC-006** — Les documents internes sont en français ; code, symboles et extraits techniques conservent leur langue naturelle.
 - **DOC-007** — Les tableaux Markdown suivent le format contrôlé par `scripts/audit_markdown_tables.py`.
+- **DOC-009** — Les cellules d'un tableau Markdown sont remplies avec des espaces afin que chaque colonne ait une largeur brute constante sur toutes les lignes de contenu.
+- **DOC-010** — La ligne séparatrice ne contient aucun espace de padding : chaque cellule séparatrice remplit exactement la largeur brute de sa colonne avec des tirets, comme dans `|-----------|----------------|`.
+- **DOC-011** — Les marqueurs Markdown d'alignement `:` ne sont utilisés que lorsqu'un alignement sémantique différent de l'alignement par défaut est nécessaire ; ils remplacent alors des tirets sans modifier la largeur brute exacte de la cellule séparatrice.
+- **DOC-012** — Les tableaux d'un même document conservent une convention cohérente et doivent passer `scripts/audit_markdown_tables.py` avant livraison.
 - **DOC-008** — Deux lignes blanches consécutives sont interdites hors blocs de code.
-- **DOC-009** — Un fichier sous `deltas/<X.Y.Z>/` décrit exactement la tranche livrée, son état de base et ses commandes de validation ; il est immuable après livraison.
-- **DOC-010** — L'historique transitoire validé réside sous `history/<X.Y.Z>/` avec un fichier immuable par jalon accepté.
-- **DOC-011** — Une entrée `history/` n'est créée qu'après validation du jalon qu'elle décrit ; le résultat d'une validation future n'est jamais pré-écrit.
-- **DOC-012** — Le delta suivant, ou le fix suivant lorsqu'il existe, crée l'entrée `history/` du dernier jalon définitivement validé si elle n'existe pas encore.
-- **DOC-013** — `CHANGELOG.md` reste une synthèse destinée aux jalons significatifs et ne reproduit pas l'historique détaillé des `pre.*` et de leurs fixes.
-- **DOC-014** — Après la structuration initiale de `0.1.0`, les `pre.*` et `.fix.*` ne modifient normalement pas `CHANGELOG.md`. Les entrées `alpha` et `beta` peuvent y apparaître uniquement lorsqu'elles correspondent à un jalon externe significatif ; `rc` et releases stables y sont les jalons privilégiés.
-- **DOC-015** — `ROADMAP.md` n'est pas modifié mécaniquement à chaque delta ; il change uniquement lorsque le périmètre, l'ordre, les objectifs ou les jalons planifiés évoluent réellement.
-- **DOC-016** — `history/` et `deltas/` ont des rôles distincts : `deltas/` décrit une livraison candidate et sa validation attendue ; `history/` enregistre le résultat accepté et durable.
+
+## Catégories documentaires
+
+- **DOC-CAT-001** — `docs/ideas/` contient des idées, variantes ou pistes non engagées. Une idée n'est ni une réservation architecturale, ni un engagement de roadmap, ni une exigence.
+- **DOC-CAT-002** — `docs/studies/` contient des analyses construites destinées à comparer des solutions, évaluer une piste ou préparer une décision. Une étude reste non normative.
+- **DOC-CAT-003** — `docs/architecture/` contient uniquement des orientations ou décisions architecturales retenues. Une possibilité encore ouverte reste dans `ideas/` ou `studies/`.
+- **DOC-CAT-004** — `docs/rules/` contient les normes obligatoires du dépôt. Une décision d'architecture ne devient une règle que lorsqu'une contrainte durable et vérifiable doit être imposée.
+- **DOC-CAT-005** — `docs/objectives/` décrit les objectifs produit et techniques ; il ne remplace ni la roadmap ni les règles.
+- **DOC-CAT-006** — Les documents spécialisés existants (`games/`, `engine/`, `monetization/`, `services/`, `development/`, `testing/`, `validation/`) conservent leur rôle fonctionnel et ne servent pas de dépôt générique d'idées.
+- **DOC-CAT-007** — Une information peut mûrir de `idea` vers `study`, puis vers une décision d'architecture ou une réservation de capability ; ce passage est explicite et n'est jamais déduit de la seule présence d'un texte.
+- **DOC-CAT-008** — Une étude peut conclure à `retained`, `deferred`, `rejected` ou `needs-poc` sans créer automatiquement une capability, une crate ou une entrée de roadmap.
+
+## Nomenclature documentaire
+
+- **DOC-NAME-001** — Les documents thématiques utilisent un préfixe numérique local à leur répertoire suivi d'un nom descriptif stable, par exemple `003-AUTH_OPTIONS.md`.
+- **DOC-NAME-002** — La séquence numérique est indépendante dans chaque répertoire documentaire.
+- **DOC-NAME-003** — Une fois un document livré, son numéro n'est pas renuméroté uniquement pour réordonner visuellement la documentation.
+- **DOC-NAME-004** — Un statut n'est pas encodé dans le nom de fichier. Les changements de statut ne provoquent donc pas de renommage mécanique.
+- **DOC-NAME-005** — Les noms de fichiers restent en anglais technique lorsqu'ils désignent un concept de projet ; le corps documentaire reste en français.
+- **DOC-NAME-006** — Le `README.md` racine du dépôt conserve ce nom canonique. Les README imposés ou naturels à une crate/package peuvent également conserver `README.md`.
+- **DOC-NAME-007** — Dans un répertoire documentaire destiné à contenir plusieurs fichiers Markdown, le point d'entrée porte le nom `000-README.md` afin d'être trié en premier.
+- **DOC-NAME-008** — Un nouveau répertoire documentaire multi-fichiers ne crée pas de `README.md` concurrent à `000-README.md`.
+
+## Listes de tâches et d'état
+
+- **DOC-TASK-001** — Toute liste Markdown qui représente durablement des tâches, objectifs ou éléments suivis utilise les marqueurs `( )`, `(x)`, `(d)` et `(c)` plutôt que les task lists Markdown `[ ]` / `[x]`.
+- **DOC-TASK-002** — `( )` signifie `planned`, `(x)` signifie `completed`, `(d)` signifie `deferred` et `(c)` signifie `cancelled`.
+- **DOC-TASK-003** — Une liste purement descriptive n'utilise pas artificiellement ces marqueurs.
+- **DOC-TASK-004** — Les règles spécialisées d'un document peuvent préciser la sémantique ou la traçabilité des marqueurs sans introduire un autre alphabet de statuts.
+
+## ROADMAP
+
+- **DOC-RMAP-001** — `ROADMAP.md` décrit le planning durable : objectifs prévus, réalisés, reportés ou annulés. Il ne suit pas le détail des prereleases et fixes.
+- **DOC-RMAP-002** — Le ROADMAP utilise les marqueurs de suivi canoniques définis par `DOC-TASK-*`.
+- **DOC-RMAP-003** — Les statuts s'appliquent aux lignes de scope et non automatiquement à une version entière.
+- **DOC-RMAP-004** — Une version peut être entièrement décrite par une seule ligne ou être ventilée en plusieurs lignes lorsque son scope a plusieurs devenirs.
+- **DOC-RMAP-005** — Une même version peut apparaître sur plusieurs lignes lorsque des sous-ensembles de son scope ont des devenirs différents.
+- **DOC-RMAP-006** — Une ligne `(x)` décrit uniquement ce qui a effectivement été livré dans la version concernée.
+- **DOC-RMAP-007** — Lorsqu'une partie du scope est reportée, elle reçoit sa propre ligne `(d)`. La destination est indiquée par `→ <version>` lorsqu'elle est connue, sinon par `→ target TBD`.
+- **DOC-RMAP-008** — Lorsqu'un élément reporté est replanifié dans une version cible, la nouvelle ligne peut indiquer `← deferred from <version>` afin d'assurer une traçabilité bidirectionnelle.
+- **DOC-RMAP-009** — Lorsqu'une partie du scope est annulée, elle reçoit sa propre ligne `(c)` ; une annulation partielle n'annule pas les éléments effectivement livrés.
+- **DOC-RMAP-010** — Une version stable clôturée ne conserve aucune ligne `( )` sous son numéro : tout scope initial doit être classé `(x)`, `(d)` ou `(c)`.
+- **DOC-RMAP-011** — Les lignes `(d)` et `(c)` restent dans la roadmap comme historique du planning et ne sont pas supprimées pour réécrire rétroactivement le plan.
+- **DOC-RMAP-012** — `ROADMAP.md` n'est pas modifié mécaniquement à chaque delta ; il change lorsque le périmètre, l'ordre, les objectifs ou le devenir d'un scope évoluent réellement.
+
+## CHANGELOG
+
+- **DOC-CHG-001** — `CHANGELOG.md` est une synthèse de publication, pas un journal de développement.
+- **DOC-CHG-002** — Les `pre.*`, `alpha.*`, `beta.*` et leurs `.fix.*` ne créent normalement aucune entrée de changelog.
+- **DOC-CHG-003** — Le changelog est mis à jour à partir des jalons `rc.*` et pour chaque release stable.
+- **DOC-CHG-004** — Une entrée RC résume l'état candidat à publication ; l'entrée stable résume le résultat effectivement publié.
+- **DOC-CHG-005** — Les détails intermédiaires de construction, corrections et validations restent dans `deltas/` et `history/`.
+- **DOC-CHG-006** — Une ancienne entrée de changelog devenue incompatible avec cette politique peut être migrée une fois vers `deltas/` / `history/` existants sans prétendre que l'ancien historique n'a jamais existé.
+
+## Deltas et historique
+
+- **DOC-DELTA-001** — Un fichier sous `deltas/<X.Y.Z>/` décrit exactement la tranche livrée, son état de base et ses validations attendues ; il est immuable après livraison.
+- **DOC-HIST-001** — L'historique transitoire validé réside sous `history/<X.Y.Z>/` avec un fichier immuable par jalon accepté.
+- **DOC-HIST-002** — Une entrée `history/` n'est créée qu'après validation du jalon qu'elle décrit ; le résultat d'une validation future n'est jamais pré-écrit.
+- **DOC-HIST-003** — Le delta suivant, ou le fix suivant lorsqu'il existe, crée l'entrée `history/` du dernier jalon définitivement validé si elle n'existe pas encore.
+- **DOC-HIST-004** — `history/` et `deltas/` ont des rôles distincts : `deltas/` décrit une livraison candidate et sa validation attendue ; `history/` enregistre le résultat accepté et durable.
+
+## Validation documentaire
+
+- **DOC-VAL-001** — Une gate Markdown ou un audit syntaxique valide la forme des documents, jamais leur exactitude fonctionnelle, leur exhaustivité ni leur acceptation.
+- **DOC-VAL-002** — Une prerelease principalement documentaire reste candidate tant que son contenu n'a pas été relu et accepté humainement.
+- **DOC-VAL-003** — Une version de conception peut utiliser plusieurs `pre.N` successives uniquement pour permettre revue, correction, complément et maturation documentaire.
+- **DOC-VAL-004** — Cargo, Gradle, packaging et smoke tests ne sont requis pour une prerelease documentaire que si le delta modifie du code, une configuration de build/runtime ou un contrat susceptible de les affecter.
+- **DOC-VAL-005** — Le document de delta énumère les validations applicables ; l'absence volontaire d'une gate technique doit découler du scope réel, pas d'un raccourci.
+- **DOC-VAL-006** — Une version documentaire n'est promue en `rc` ou stable qu'après validation explicite de son contenu, même si tous les audits automatisés sont propres.
+
+## Maturation des idées et capabilities
+
+- **DOC-MAT-001** — La chaîne de maturation conceptuelle de référence est `Idea → Study → Architectural decision → Reserved capability → Planned → Implemented`.
+- **DOC-MAT-002** — Une branche peut s'arrêter en `Deferred` ou `Rejected` à n'importe quelle étape pertinente.
+- **DOC-MAT-003** — `Reserved` signifie que le concept et sa place architecturale sont reconnus sans engagement d'implémentation ni de version.
+- **DOC-MAT-004** — `Planned` signifie qu'une implémentation est affectée à une version ou un jalon de roadmap.
+- **DOC-MAT-005** — `Experimental` signifie qu'un POC ou une implémentation d'évaluation existe ou est explicitement planifié ; ce statut ne remplace pas `Reserved` pour une simple possibilité.
+- **DOC-MAT-006** — Une idée purement spéculative ne devient pas une capability réservée uniquement pour préserver une possibilité future.
+
+## Immutabilité des deltas
+
+- **DOC-DELTA-002** — Un fichier `deltas/**/*.md` livré est immuable sur le fond. Il ne reçoit jamais ultérieurement de nouveau scope, de nouvelle règle, de nouvelle validation, de nouveau résultat ou de nouvelle justification.
+- **DOC-DELTA-003** — Une correction strictement non sémantique d'un delta livré est autorisée uniquement pour la forme : orthographe, typographie, alignement de tableau ou correction mécanique équivalente.
+- **DOC-DELTA-004** — Toute correction autorisée par `DOC-DELTA-003` incrémente le numéro `version` d'en-tête du fichier corrigé.
+- **DOC-DELTA-005** — Toute correction sémantique ou tout ajout produit un nouveau delta ou un nouveau `.fix.N` ; l'ancien delta reste inchangé.
+- **DOC-DELTA-006** — Un fichier `deltas/**/*.delete.txt` fait partie du contrat de livraison et doit être documenté explicitement par le fichier Markdown du même delta.
+- **DOC-DELTA-007** — Un manifest `*.delete.txt` contient uniquement des chemins relatifs à la racine, un par ligne. Le delta associé documente la raison des suppressions et la commande d'application.
+
+## Versions d'en-tête
+
+- **DOC-HEAD-001** — Tout fichier géré par le projet qui possède un en-tête `version` incrémente ce numéro lors de toute modification réelle de contenu.
+- **DOC-HEAD-002** — Une modification réelle inclut ajout, suppression, déplacement, reformulation, changement de valeur de configuration, changement de contrat ou changement de chemin dans l'en-tête `file:`.
+- **DOC-HEAD-003** — Une transformation purement mécanique par un formatter officiel du projet, telle que `cargo fmt`, ne déclenche pas à elle seule d'incrément de version.
+- **DOC-HEAD-004** — Si un formatter est exécuté après une modification réelle du fichier, l'incrément reste requis à cause de la modification réelle.
+- **DOC-HEAD-005** — Un nouveau fichier versionné commence normalement à `version: 1`.

docs/rules/RULES_PROJECT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_PROJECT.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Règles spécifiques games.sasedev
 
@@ -75,3 +75,16 @@
 
 - **GAME-PLATFORM-014** — Pour une launcher Activity Android racine, Back reste une navigation système. Le projet ne doit pas enregistrer de callback consommant Back uniquement pour logger ou exécuter de la logique métier ; sur API 36+, un `PRIORITY_SYSTEM_NAVIGATION_OBSERVER` peut observer l'action sans bloquer le Back-to-home.
 - **GAME-PLATFORM-015** — Les exécutables Android initialisent le subscriber partagé et envoient les événements `tracing` vers logcat ; `stderr` n'est pas la destination Android de référence.
+
+## Réservation de plateformes
+
+- **GAME-PLATFORM-016** — Les familles de plateformes réservées sont Desktop, Mobile et Web. Desktop inclut potentiellement Linux, Windows et macOS ; Mobile inclut potentiellement Android et iOS.
+- **GAME-PLATFORM-017** — Téléphone, tablette et futures classes de device sont des dimensions distinctes de l'OS et du backend technique.
+- **GAME-PLATFORM-018** — SDL3 reste le backend natif de référence du POC, mais l'architecture de jeu ne doit pas assimiler une plateforme à SDL ni empêcher un adapter différent lorsque la plateforme l'exige.
+- **GAME-PLATFORM-019** — Une plateforme réservée n'est ni implémentée ni planifiée tant qu'une ligne ROADMAP ou un delta ne l'engage explicitement.
+
+## Version d'en-tête des fichiers
+
+- **GAME-FILE-001** — Toute modification réelle d'un fichier qui possède un en-tête `version` incrémente ce numéro.
+- **GAME-FILE-002** — Les transformations purement mécaniques réalisées par les formatters officiels n'incrémentent pas à elles seules cet en-tête.
+- **GAME-FILE-003** — Un changement du champ d'en-tête `file:` dû à un renommage est une modification réelle et incrémente la version.

docs/rules/RULES_SERVER_HOSTING.md

@@ -0,0 +1,31 @@
+<!-- file: docs/rules/RULES_SERVER_HOSTING.md -->
+<!-- version: 1 -->
+
+# Règles de portabilité et d'auto-hébergement serveur
+
+## Portabilité
+
+- **HOST-001** — Le logiciel serveur Rust reste indépendant d'une version précise de distribution Linux au niveau métier.
+- **HOST-002** — Les dépendances propres au déploiement, à `systemd`, au firewall, au reverse proxy, aux certificats et au layout filesystem restent hors du domaine métier.
+- **HOST-003** — Une décision d'infrastructure ne doit pas contaminer les crates de gameplay ou les contrats réseau publics.
+
+## Cible opérationnelle préférée
+
+- **HOST-010** — La cible d'auto-hébergement de référence est Debian Stable.
+- **HOST-011** — Debian 13 « trixie » est l'environnement courant de développement/test serveur, sans constituer une dépendance fonctionnelle à cette version.
+- **HOST-012** — Les paquets des dépôts officiels Debian sont préférés.
+- **HOST-013** — Les dépôts tiers sont évités par défaut et ne sont admis que pour un outil spécifique lorsque le besoin est justifié et la source suffisamment stable.
+- **HOST-014** — Ubuntu LTS peut être évalué comme solution secondaire lorsqu'une contrainte technique matérielle rend Debian impraticable ; il n'est pas la cible par défaut.
+
+## Choix futurs d'infrastructure
+
+- **HOST-020** — Les choix futurs tels que HAProxy, nginx, serveur HTTP/3, stockage objet ou autres composants sont évalués au moment du POC/déploiement correspondant.
+- **HOST-021** — Leur compatibilité avec Debian Stable, leur maturité, leur disponibilité sans dépôt tiers, leur maintenance et leur support de protocole font partie des critères.
+- **HOST-022** — Aucun composant edge/reverse-proxy n'est figé par `0.2.0`.
+
+## Auto-hébergement progressif
+
+- **HOST-030** — Les services peuvent commencer sur une même machine avec séparation logique par service/hostname.
+- **HOST-031** — La séparation physique sur plusieurs machines est motivée par charge, sécurité, isolation ou cycle de déploiement.
+- **HOST-032** — L'architecture doit permettre de déplacer Web/API, assets, realtime, base de données et media/replay sans modifier les règles Uroburas.
+- **HOST-033** — Un CDN tiers n'est pas une dépendance obligatoire ; l'asset delivery auto-hébergé et sa distribution progressive restent une trajectoire supportée.

docs/rules/RULES_SESSION_PLANNING.md

@@ -0,0 +1,49 @@
+<!-- file: docs/rules/RULES_SESSION_PLANNING.md -->
+<!-- version: 1 -->
+
+# Règles de cadrage des versions, sessions et prompts
+
+## Objet
+
+Ces règles imposent un découpage suffisamment petit pour qu'une version puisse être développée complètement dans une seule session et reprise sans ambiguïté.
+
+## `pre.1` — cadrage obligatoire
+
+- **SESSION-001** — Toute nouvelle version commence par une `0-pre.1` de cadrage.
+- **SESSION-002** — Cette tranche couvre au minimum l'audit de la base, le brainstorming/recherche de requirements, le sizing, les dépendances, les validations prévues et le découpage prévisionnel.
+- **SESSION-003** — Une première implémentation peut être incluse dans `0-pre.1` uniquement si elle est petite, cohérente et n'empêche pas le cadrage d'être terminé.
+- **SESSION-004** — Si le sizing montre que l'objectif global ne peut raisonnablement pas être terminé dans la session, il est scindé en plusieurs versions avant le développement lourd.
+
+## Taille des tranches
+
+- **SESSION-010** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou `fix.N` vise normalement un delta correspondant à environ 15 à 30 minutes de travail effectif.
+- **SESSION-011** — Une tranche clairement plus lourde est scindée avant exécution.
+- **SESSION-012** — Plusieurs micro-tranches sans valeur de validation indépendante peuvent être regroupées.
+- **SESSION-013** — Le découpage suit des unités fonctionnelles complètes et validables ; une fonctionnalité ne doit pas être volontairement coupée au milieu uniquement pour respecter un numéro de prerelease.
+- **SESSION-014** — Chaque tranche livre son delta et ses validations proportionnelles avant la tranche suivante.
+
+## Une version par session
+
+- **SESSION-020** — Une session de développement vise une version complète, de son cadrage jusqu'à sa release ou à sa candidate de publication selon le scope décidé.
+- **SESSION-021** — Une session ne doit pas être planifiée de façon à s'arrêter normalement au milieu d'une version.
+- **SESSION-022** — Si de nouvelles informations rendent la version trop grande, le scope restant est replanifié explicitement vers une version suivante au lieu de prolonger indéfiniment la session.
+
+## Dernières tranches
+
+- **SESSION-030** — Les dernières tranches consolident les validations, la documentation durable, `CHANGELOG.md`, `ROADMAP.md`, l'historique applicable et le prompt de la prochaine session.
+- **SESSION-031** — La release stable reste autant que possible mécanique et n'introduit pas de nouveau scope fonctionnel ou architectural.
+
+## Prompt de prochaine session
+
+- **PROMPT-001** — Le prompt suivant est préparé à partir d'un état réellement validé ; il ne prétend jamais qu'une validation future a déjà été exécutée.
+- **PROMPT-002** — Le prompt indique la base exacte, la version cible, l'objectif, le scope inclus/exclus, les décisions gelées, les points ouverts et les validations attendues.
+- **PROMPT-003** — Le prompt distingue explicitement les résultats déjà validés des commandes à exécuter dans la nouvelle session.
+- **PROMPT-004** — Le prompt donne une trajectoire prévisionnelle des tranches sans rendre cette prévision immuable.
+- **PROMPT-005** — Le prompt rappelle les invariants essentiels mais renvoie aux RULES pour les détails normatifs au lieu de les recopier intégralement.
+- **PROMPT-006** — Le prompt contient suffisamment de contexte pour reprendre la version sans dépendre de la mémoire conversationnelle ni relire toute l'histoire du dépôt.
+- **PROMPT-007** — Le prompt précise la condition de fin de session et les livrables attendus.
+- **PROMPT-008** — Si `pre.1` invalide le sizing prévu par le prompt, le nouveau découpage est documenté immédiatement avant le développement lourd.
+
+## Relation avec VERSION_WORKFLOW
+
+`VERSION_WORKFLOW.md` définit le cycle SemVer et la maturation. Le présent document précise comment dimensionner et transmettre une session de travail.

docs/rules/RULES_VALIDATION_MATRIX.md

@@ -0,0 +1,77 @@
+<!-- file: docs/rules/RULES_VALIDATION_MATRIX.md -->
+<!-- version: 2 -->
+
+# Matrice normative des commandes et validations
+
+## Principes
+
+La matrice associe un identifiant stable à chaque famille de commandes. Le delta sélectionne les commandes applicables selon les fichiers touchés, leurs dépendances et la phase de maturité.
+
+Une commande dépendante n'est exécutée que lorsque ses prérequis applicables sont propres.
+
+Les commandes ciblées restent la norme pendant l'implémentation ; les gates workspace et les smokes de distribution deviennent plus larges à mesure que la version approche de beta/RC.
+
+## Matrice
+
+| ID        | Commande / action                                                                  | Dépend de                           | Déclencheur principal                      | Phase minimale typique |
+|-----------|------------------------------------------------------------------------------------|-------------------------------------|--------------------------------------------|------------------------|
+| `CMD-001` | `cargo fmt --all`                                                                  | —                                   | source Rust modifié                        | `pre`                  |
+| `CMD-002` | `cargo fmt --all -- --check`                                                       | `CMD-001` si formatage requis       | source Rust modifié                        | `pre`                  |
+| `CMD-010` | `python3 scripts/audit_rust_workspace_rules.py`                                    | —                                   | Rust/workspace/règles Rust                 | `pre`                  |
+| `CMD-011` | `python3 scripts/audit_markdown_tables.py ...`                                     | —                                   | Markdown/règles/docs                       | `pre`                  |
+| `CMD-012` | `python3 scripts/audit_distribution_layout.py`                                     | —                                   | layout/build/distribution                  | `pre`                  |
+| `CMD-020` | `cargo check -p <crate>`                                                           | `CMD-002`, `CMD-010`                | crate Rust ciblée                          | `pre`                  |
+| `CMD-021` | `cargo test -p <crate> --all-targets --all-features`                               | `CMD-020`                           | comportement/API crate                     | `pre`                  |
+| `CMD-022` | tests des crates consommatrices impactées                                          | `CMD-021`                           | API publique/contrat partagé modifié       | `pre`                  |
+| `CMD-023` | `cargo check --workspace`                                                          | audits applicables                  | changement transverse / gate globale       | selon portée           |
+| `CMD-024` | `cargo clippy --workspace --all-targets --all-features -- -D warnings`             | `CMD-023`                           | gate complète                              | alpha/beta/RC          |
+| `CMD-025` | `cargo test --workspace --all-targets --all-features`                              | `CMD-024`                           | changement transverse / frontière de phase | beta/RC                |
+| `CMD-030` | build Desktop `--release` ciblé                                                    | gates Rust applicables              | runner/distribution Desktop touché         | beta                   |
+| `CMD-031` | smoke Desktop release                                                              | `CMD-030`                           | runtime Desktop touché                     | beta                   |
+| `CMD-040` | `cargo tauri build`                                                                | gates Rust/frontend applicables     | périmètre Tauri touché                     | beta                   |
+| `CMD-041` | smoke Tauri release                                                                | `CMD-040`                           | runtime Tauri touché                       | beta                   |
+| `CMD-050` | build Rust Android ABI ciblé                                                       | gates Rust applicables              | Android/JNI/backend natif touché           | pre/beta               |
+| `CMD-051` | Gradle `assembleDebug` application ciblée                                          | `CMD-050` lorsque Rust natif change | Android/app/manifest/Java touché           | pre/beta               |
+| `CMD-052` | install + smoke AVD                                                                | `CMD-051`                           | Android concerné                           | beta                   |
+| `CMD-053` | install + smoke appareil réel                                                      | `CMD-051`                           | Android concerné                           | beta/RC                |
+| `CMD-060` | `cargo clean --dry-run --verbose`                                                  | —                                   | contrôle disque / préparation nettoyage    | maintenance            |
+| `CMD-061` | `cargo clean`                                                                      | décision explicite de nettoyage     | accumulation disque / jalon de cycle       | maintenance            |
+| `CMD-062` | `cargo clean -p <package>` ou nettoyage par `--release` / `--profile` / `--target` | —                                   | nettoyage ciblé suffisant                  | maintenance            |
+
+## Dépendances entre crates
+
+Lorsqu'une crate `A` change :
+
+1. exécuter les validations ciblées de `A` ;
+2. déterminer les consommateurs dont le contrat est affecté ;
+3. exécuter les validations ciblées des consommateurs concernés ;
+4. passer aux gates workspace lorsque la portée ne peut plus être bornée raisonnablement ou lorsqu'une frontière de maturité l'exige.
+
+Une modification interne sans changement de contrat ne force pas mécaniquement tous les consommateurs transitifs à être retestés.
+
+Une modification d'API publique, de représentation partagée, de feature structurante ou de comportement contractuel élargit la portée des tests.
+
+## Nettoyage Cargo et contrôle disque
+
+Le projet utilise `../builds/sasedev-games/target` comme `target-dir`. Cette zone peut accumuler plusieurs profils, triples cibles, artefacts incrémentaux et anciennes variantes au cours d'un cycle de développement.
+
+La politique est donc double :
+
+- utiliser `CMD-062` lorsqu'un nettoyage ciblé suffit ;
+- utiliser `CMD-061` périodiquement afin d'éviter une croissance non bornée du répertoire de build.
+
+Le nettoyage complet est normalement positionné au début d'un nouveau cycle de développement lorsque l'on souhaite évacuer les artefacts de la version précédente, ou avant une validation finale RC/stable lorsqu'un rebuild propre est recherché et que l'espace disque le justifie.
+
+Le delta ou le plan de version indique quel jalon de nettoyage est retenu. Il n'est pas nécessaire d'exécuter `cargo clean` à chaque prerelease.
+
+## Vérification des versions d'en-tête
+
+Avant livraison d'un delta :
+
+1. fichier modifié réellement et déjà versionné → en-tête incrémenté ;
+2. fichier uniquement reformaté mécaniquement → en-tête inchangé ;
+3. nouveau fichier versionné → `version: 1` sauf règle spécialisée ;
+4. renommage modifiant `file:` → en-tête incrémenté ;
+5. delta antérieur → aucun ajout sémantique rétroactif.
+
+Cette vérification fait partie de la revue de livraison même lorsqu'aucun audit automatisé ne dispose encore de la version précédente pour comparer.

docs/rules/VERSION_WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/VERSION_WORKFLOW.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->
 
 # Versionnement, maturité et livraisons
 
@@ -73,3 +73,65 @@ deltas/0.1.0/1-alpha.1.md
 deltas/0.1.0/3-rc.2.md
 deltas/0.1.0/rel.md
 ```
+
+## Versions principalement documentaires
+
+Une version de conception suit le même SemVer que les autres versions et peut utiliser plusieurs `0-pre.N` pour permettre une revue humaine progressive.
+
+Les audits Markdown et de règles valident la cohérence mécanique mais ne valent jamais acceptation du fond documentaire. Une prerelease documentaire reste candidate jusqu'à revue explicite de son contenu.
+
+Les gates techniques sont proportionnelles aux fichiers touchés :
+
+- un delta uniquement documentaire exécute les audits documentaires applicables ;
+- une modification Rust déclenche les gates Rust prévues par les règles ;
+- une modification Android/Gradle déclenche les gates Android concernées ;
+- une modification Tauri/frontend/build déclenche les gates correspondantes.
+
+La promotion `rc` puis stable d'une version de conception exige une validation humaine explicite du contenu consolidé.
+
+## Travail en RC
+
+- **VER-RC-001** — Une RC est fonctionnellement gelée. Les nouvelles fonctionnalités, nouvelles capabilities, refactors architecturaux non indispensables et changements volontaires de comportement sont interdits.
+- **VER-RC-002** — Les modifications de code restent autorisées en RC lorsqu'elles corrigent un bug, un test erroné, un défaut de packaging, un problème de sécurité, une incompatibilité de release ou un défaut strictement nécessaire à la publication.
+- **VER-RC-003** — Un correctif conforme à `VER-RC-002` produit `3-rc.N.fix.M` et n'impose pas un retour automatique en beta.
+- **VER-RC-004** — Si le périmètre fonctionnel est rouvert pendant une RC, la candidate est abandonnée et le développement revient à une phase adaptée, normalement beta, avant une nouvelle RC.
+
+## Prompt de la version suivante
+
+- **VER-PROMPT-001** — Le prompt de démarrage de la version suivante n'est pas créé à un numéro arbitraire de RC.
+- **VER-PROMPT-002** — Sa génération devient recommandée après validation de la première RC dont le périmètre est effectivement gelé.
+- **VER-PROMPT-003** — Le prompt peut être complété pendant les fixes RC ou la release stable, mais ne doit pas contenir de résultats futurs présentés comme déjà validés.
+
+## Phases de développement
+
+Une version suit conceptuellement :
+
+```text
+PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE
+```
+
+- **VER-PHASE-001** — Ces phases structurent le travail mais n'imposent pas une prerelease distincte pour chacune.
+- **VER-PHASE-002** — `0-pre.1` est obligatoirement la tranche de cadrage de la version : audit de la base, brainstorming/recherche de requirements, sizing, planification, dépendances, validations attendues et découpage prévisionnel.
+- **VER-PHASE-003** — `0-pre.1` peut aussi contenir une première implémentation strictement bornée si le cadrage montre qu'elle tient naturellement dans la même tranche, mais le cadrage ne doit jamais être sauté.
+- **VER-PHASE-004** — Une version doit être dimensionnée pour que l'ensemble de son développement puisse être terminé dans une seule session de travail. Si ce n'est pas réaliste, son objectif est découpé en plusieurs versions/sessions avant le développement lourd.
+- **VER-PHASE-005** — Le plan établi en `0-pre.1` est vivant : il peut regrouper, scinder, reporter ou reclasser des tranches lorsque l'information réelle le justifie, sans réécrire les deltas déjà livrés.
+- **VER-PHASE-006** — Une tranche `pre.N`, `alpha.N`, `beta.N`, `rc.N` ou leur fix vise normalement un delta réalisable en environ 15 à 30 minutes. Une tranche sensiblement plus lourde est découpée avant exécution ; une tranche trop petite peut être regroupée avec une tranche adjacente cohérente.
+- **VER-PHASE-007** — Le découpage privilégie des unités fonctionnelles complètes et validables, pas des coupures arbitraires au milieu d'une fonctionnalité.
+- **VER-PHASE-008** — Chaque tranche ferme son propre scope, produit son delta et ses validations proportionnelles avant l'ouverture de la tranche suivante.
+- **VER-PHASE-009** — Alpha, beta et RC sont utilisées proportionnellement au risque et à la maturité ; elles ne sont pas créées uniquement pour satisfaire une séquence cérémonielle.
+- **VER-PHASE-010** — La dernière tranche de développement avant la candidate de publication est réservée à la consolidation : validations finales, documentation durable, `CHANGELOG.md`, `ROADMAP.md`, historique applicable et préparation du prompt de la version/session suivante.
+- **VER-PHASE-011** — La release stable est autant que possible mécanique : elle ne doit pas introduire une nouvelle fonctionnalité, une nouvelle décision architecturale ou un nouveau scope non validé dans une candidate précédente.
+
+## Versions Tauri/frontend
+
+- **VER-TAURI-001** — Pour une app Tauri Rust du workspace, la version produit canonique est la version Cargo.
+- **VER-TAURI-002** — `tauri.conf.json` omet `version` lorsque Tauri peut hériter de la version `Cargo.toml`.
+- **VER-TAURI-003** — La `version` de `package.json` décrit le package frontend local et n'est pas synchronisée à chaque `pre.N` ou `.fix.N`.
+- **VER-TAURI-004** — Tant que le frontend n'est pas publié comme package npm, sa version est mise à jour uniquement aux jalons significatifs retenus par le projet, au minimum lorsque cela est nécessaire pour alpha, beta, RC ou stable.
+
+## Corrections des deltas déjà livrés
+
+- **VER-DELTA-001** — Un delta livré n'est jamais enrichi après coup.
+- **VER-DELTA-002** — Une correction purement orthographique, typographique, d'alignement ou de forme sans changement de sens peut être appliquée au fichier delta existant si son en-tête `version` est incrémenté.
+- **VER-DELTA-003** — Une correction qui change le sens, le scope, les validations, les suppressions ou les décisions produit un nouveau `.fix.N`.
+- **VER-DELTA-004** — Les manifests `*.delete.txt` sont toujours décrits dans le delta Markdown qui les introduit.

docs/studies/000-README.md

@@ -0,0 +1,55 @@
+<!-- file: docs/studies/000-README.md -->
+<!-- version: 8 -->
+
+# Études
+
+Ce répertoire accueille les analyses construites qui comparent des solutions, évaluent une piste ou préparent une décision.
+
+Une étude reste non normative. Elle peut conclure notamment à :
+
+- `retained` ;
+- `deferred` ;
+- `rejected` ;
+- `needs-poc`.
+
+Une conclusion `retained` ne crée pas à elle seule une règle, une capability ou une entrée de roadmap. La décision résultante doit être portée explicitement dans le document architectural ou normatif approprié.
+
+Les études conservent les alternatives et raisons utiles à la compréhension future, y compris lorsqu'une piste est rejetée.
+
+## Études 0.2.0
+
+- [`001-FUNCTIONAL_CAPABILITY_INVENTORY.md`](001-FUNCTIONAL_CAPABILITY_INVENTORY.md) — inventaire fonctionnel initial sans engagement d'implémentation.
+- [`002-LAYERING_AND_OWNERSHIP_STUDY.md`](002-LAYERING_AND_OWNERSHIP_STUDY.md) — étude du découpage kernel, capability, game-system, plateforme, provider, service et jeu.
+- [`003-PLATFORM_CAPABILITY_STUDY.md`](003-PLATFORM_CAPABILITY_STUDY.md) — axes plateforme/device/host/backend et disponibilité des capacités.
+- [`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.
+
+## Études POC plateforme
+
+- [`009-PLATFORM_POC_CANDIDATES.md`](009-PLATFORM_POC_CANDIDATES.md) — inventaire des POC plateforme focalisés sur Snake comme jeu-sonde unique.
+- [`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.
+
+## Étude du prochain jeu réel
+
+- [`013-UROBURAS_FUNCTIONAL_SPEC.md`](013-UROBURAS_FUNCTIONAL_SPEC.md) — spécification fonctionnelle initiale de Uroburas.
+- [`014-UROBURAS_MODES_AND_SESSION_RULES.md`](014-UROBURAS_MODES_AND_SESSION_RULES.md) — Challenge, PvP Battles et Persistent Battle Royale.
+- [`015-UROBURAS_MAP_ASSET_AND_UGC_SPEC.md`](015-UROBURAS_MAP_ASSET_AND_UGC_SPEC.md) — maps/assets téléchargés, règles de map, éditeur et UGC.
+- [`016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md`](016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md) — armes, protections et interactions tête/corps/queue.
+- [`017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md`](017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md) — score, vies, rewarded continue/rejoin et classements.
+- [`018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md`](018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md) — spectator, bots, replay, streaming et vidéo régénérée.
+
+## Classification Uroburas avant implémentation
+
+- [`019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md`](019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md) — mapping des fonctionnalités vers kernel, capabilities, game-systems, Uroburas, server, provider, platform et tooling.
+- [`020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md`](020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md) — proposition de familles de crates et dépendances sans monolithe jeu.
+- [`021-UROBURAS_SERVER_REFERENCE_STACK.md`](021-UROBURAS_SERVER_REFERENCE_STACK.md) — stack serveur de référence Actix/Tokio/tokio-tungstenite/Maud/Fluent/Lettre et gRPC/Tonic conditionnel.
+- [`022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md`](022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md) — ordre d'implémentation recommandé pour le Mode 1 avant les modes multijoueurs.

docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md

@@ -0,0 +1,488 @@
+<!-- file: docs/studies/001-FUNCTIONAL_CAPABILITY_INVENTORY.md -->
+<!-- version: 3 -->
+
+# Inventaire fonctionnel initial
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+Le but est d'identifier les besoins plausibles déjà justifiés par les jeux et plateformes envisagés. La présence d'une entrée ne signifie ni crate à créer, ni API figée, ni version d'implémentation engagée.
+
+## Principe de classement
+
+Chaque besoin doit finir dans l'une des familles suivantes :
+
+- **kernel** — primitive minimale nécessaire au fonctionnement générique du moteur ;
+- **technical capability** — service technique réutilisable exposé au jeu ;
+- **game-system** — mécanique de gameplay réutilisable entre plusieurs jeux ;
+- **platform adapter** — implémentation d'un contrat pour un OS, host ou backend ;
+- **provider** — intégration d'un service externe interchangeable ;
+- **server service** — autorité ou service distant partagé ;
+- **tooling** — construction, génération, validation ou distribution ;
+- **game-specific** — règle propre à un jeu qui ne doit pas être généralisée prématurément.
+
+## Kernel candidat
+
+Le kernel doit rester volontairement petit.
+
+Candidats déjà justifiés :
+
+- lifecycle générique `start / update / render / stop` ;
+- horloge monotone et temps de frame ;
+- fixed-step ou scheduling déterministe lorsque requis ;
+- abstraction d'événements/runtime sans dépendance directe au jeu ;
+- contexte runtime/provenance déjà introduit en `0.1.0` ;
+- contrats minimaux nécessaires pour connecter input et rendu ;
+- politique de quit/lifecycle indépendante de SDL/Android/Tauri.
+
+À challenger avant décision :
+
+- scene stack ;
+- scheduler générique ;
+- ECS ;
+- task graph ;
+- event bus généraliste.
+
+Ces éléments ne doivent pas être réservés uniquement parce qu'ils sont courants dans d'autres moteurs.
+
+## Technical capabilities candidates
+
+### Input
+
+Besoins identifiés :
+
+- actions sémantiques indépendantes des touches physiques ;
+- clavier ;
+- souris/pointer ;
+- tactile ;
+- gestes ;
+- contrôles virtuels affichés ;
+- gamepad ;
+- bindings configurables ;
+- profils par produit et plateforme ;
+- multi-player local avec plusieurs périphériques lorsque le jeu le demande.
+
+Le jeu consomme des actions telles que `MoveUp`, `PrimaryAction` ou `Pause`, pas `KeyW` ou `SwipeUp`.
+
+### Rendering
+
+Besoins identifiés :
+
+- dessin 2D ;
+- sprites ;
+- textures ;
+- texte ;
+- viewport/résolution virtuelle ;
+- caméra 2D pour cartes plus grandes que l'écran ;
+- couches/z-order ;
+- animation sprite-sheet ;
+- primitives simples de debug.
+
+La 3D n'est pas réservée à ce stade.
+
+### Audio
+
+Besoins identifiés :
+
+- effets sonores ;
+- musique ;
+- volume/mute ;
+- lifecycle audio mobile ;
+- éventuellement groupes/bus simples.
+
+La voix temps réel reste une idée/étude future liée à un cas de jeu concret.
+
+### Assets
+
+Besoins identifiés :
+
+- assets embarqués ;
+- assets communs et propres au jeu ;
+- résolution logique des chemins ;
+- variantes par densité/résolution si nécessaire ;
+- téléchargement/cache d'assets distants pour certains jeux futurs ;
+- intégrité/version d'asset lorsqu'un CDN sera réellement introduit.
+
+### Persistence locale
+
+Besoins identifiés :
+
+- préférences ;
+- save-game ;
+- progression locale ;
+- cache ;
+- journal/outbox pour online-optional à terme.
+
+Les garanties exactes de transaction, migration et chiffrement seront étudiées quand un jeu les exigera.
+
+### Networking client
+
+Besoins identifiés :
+
+- HTTP(S) ;
+- WebSocket ;
+- reconnexion ;
+- timeout/backoff ;
+- protocole versionné côté jeu/service ;
+- état de connectivité ;
+- séparation transport/protocole.
+
+WebRTC et gRPC restent des solutions à étudier pour des usages précis et ne sont pas imposés au framework général.
+
+### Logging/diagnostics
+
+Besoins identifiés :
+
+- `tracing` commun ;
+- domaines par crate/sous-système ;
+- niveau maximal déterminé par produit/build ;
+- filtrage runtime dans la limite de ce qui a été compilé ;
+- logs Android/logcat, Desktop et Tauri ;
+- métriques/telemetry ultérieures sans les confondre avec le logging.
+
+### Identity/auth client
+
+Besoins identifiés :
+
+- joueur anonyme ;
+- compte requis ;
+- upgrade anonyme vers compte ;
+- identité canonique propre au backend ;
+- liaison d'identités externes ;
+- session/token ;
+- déconnexion et changement de compte.
+
+Google, Play Games, Apple, Steam ou autres sont des providers, pas l'identité canonique du moteur.
+
+### Monetization client
+
+Besoins identifiés :
+
+- rewarded ad ;
+- interstitial éventuel selon jeu ;
+- disponibilité/cooldown ;
+- résultat `completed / skipped / failed / unavailable` ;
+- absence complète de monétisation sur certaines plateformes/produits ;
+- achats intégrés futurs si un jeu en a besoin.
+
+Les régies spécifiques restent des providers.
+
+## Game-systems candidats
+
+### Score et objectifs
+
+- score ;
+- combo/multiplicateur ;
+- chronomètre ;
+- objectifs ;
+- calcul de résultat final.
+
+Le calcul exact reste contrôlé par le jeu.
+
+### Lives / attempts
+
+- nombre de vies ou tentatives ;
+- consommation/restauration ;
+- politique de game-over ;
+- recharge éventuelle.
+
+### Energy / stamina
+
+- réserve courante/maximale ;
+- coût d'action ;
+- recharge temporelle ;
+- recharge par reward/ad/inventory ;
+- politique offline éventuelle.
+
+### Progression / XP / levels
+
+- expérience ;
+- niveaux ;
+- seuils ;
+- progression débloquée ;
+- récompenses de niveau.
+
+La notion de « level » de progression ne doit pas être confondue avec une map/stage.
+
+### Inventory / items
+
+- item type/id ;
+- quantité ;
+- capacité ;
+- acquisition/consommation ;
+- metadata de gameplay ;
+- sérialisation.
+
+Équipement, crafting, rareté ou économie ne sont pas imposés au noyau inventaire tant qu'un jeu ne les exige pas.
+
+### Grid / tile map
+
+Besoins identifiés par Snake, Sokoban et aventure puzzle :
+
+- coordonnées de grille ;
+- taille de cellule ;
+- occupancy ;
+- tile map ;
+- couches ;
+- obstacles ;
+- wrap/no-wrap ;
+- spawn zones ;
+- chargement de map.
+
+### Collision 2D
+
+Plusieurs niveaux possibles :
+
+- collision grille/cellule ;
+- AABB ;
+- formes simples ;
+- collision continue/physique avancée.
+
+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 :
+
+- seed ;
+- ruleset versionné ;
+- génération reproductible ;
+- horodatage relatif ;
+- replay ou validation partielle ultérieure.
+
+### Puzzle systems
+
+Systèmes potentiellement réutilisables, mais à ne créer qu'après second consommateur ou besoin clair :
+
+- Sokoban-like push blocks ;
+- pipe/plumber connectivity ;
+- laser/mirror ray routing ;
+- switches/doors ;
+- collect-and-unlock.
+
+### Navigation/map progression
+
+Pour aventure/puzzle :
+
+- stages/maps ;
+- transitions ;
+- checkpoints ;
+- unlock graph.
+
+À distinguer du `Progression/XP`.
+
+### Racing systems
+
+Candidats si un projet racing est lancé :
+
+- checkpoints ;
+- laps ;
+- start grid ;
+- race timer ;
+- classement en course ;
+- ghost/replay ;
+- synchronisation multiplayer.
+
+La physique de véhicule reste hors du framework général tant qu'elle n'est pas justifiée.
+
+### Combat systems
+
+Candidats pour fighting/hack'n slash/MMORPG :
+
+- health/damage ;
+- cooldown ;
+- hit/hurt boxes ;
+- status effects ;
+- abilities ;
+- target selection.
+
+Ils ne sont pas réservés comme API aujourd'hui ; ils identifient seulement une pression architecturale future.
+
+## Platform adapters candidates
+
+Les adapters implémentent les contrats techniques sans contenir la logique de jeu.
+
+Cibles déjà identifiées ou réservées :
+
+- SDL3 native Desktop ;
+- SDL3 Android ;
+- Web/WASM ;
+- Tauri Desktop host ;
+- Tauri Android host expérimental futur ;
+- macOS natif réservé ;
+- iOS natif réservé.
+
+L'OS, la classe de device, l'execution model et le host restent des dimensions distinctes.
+
+## Providers candidates
+
+Providers externes déjà justifiés par les objectifs :
+
+- ads : AdMob, puis autres régies si besoin ;
+- identity : Google/OAuth, Play Games, Apple/Steam ultérieurement selon plateforme ;
+- leaderboard : backend propre et/ou provider plateforme ;
+- cloud storage : backend propre ;
+- assets/CDN : provider de stockage/CDN ;
+- paiement/IAP : stores plateforme ;
+- crypto reward/wallet : provider isolé uniquement pour un projet PKE concerné.
+
+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 :
+
+- auth/identity ;
+- profile ;
+- save/progression cloud ;
+- leaderboard ;
+- inventory/economy authoritative lorsqu'une valeur partagée existe ;
+- configuration/rulesets distants ;
+- asset metadata/CDN orchestration ;
+- administration/modération selon besoins ;
+- anti-cheat/validation de résultats ;
+- reward authority pour tout jeu avec valeur monétaire ou crypto.
+
+Ces services peuvent être exposés en HTTP(S) et ne doivent pas être placés dans la boucle temps réel uniquement parce qu'un jeu possède aussi un mode multijoueur.
+
+### Lobby / matchmaking / session control
+
+Besoins identifiés :
+
+- création et découverte de partie ;
+- invitation/join/leave ;
+- matchmaking ;
+- allocation d'une room/session ;
+- roster de joueurs ;
+- ready/start/end ;
+- reprise de session ;
+- spectator policy éventuelle ;
+- routing vers l'instance realtime responsable.
+
+Le control plane d'une partie peut être séparé du data plane temps réel.
+
+### Realtime multiplayer server
+
+Capacités à étudier explicitement :
+
+- endpoint/gateway WebSocket ou transport realtime équivalent ;
+- authentification et attachement d'une connexion à une session ;
+- ingestion d'inputs/commands client plutôt que confiance dans un état client arbitraire ;
+- tick ou cadence serveur ;
+- simulation/état authoritative lorsque le jeu l'exige ;
+- ordre des messages, sequence numbers et déduplication ;
+- acknowledgement lorsque nécessaire ;
+- snapshots complets ;
+- deltas/patches entre snapshots ;
+- version/revision de l'état ;
+- interest management pour ne diffuser qu'un sous-ensemble pertinent du monde ;
+- broadcast/multicast par room ;
+- backpressure et limites de file ;
+- détection de timeout/heartbeat ;
+- disconnect/reconnect ;
+- reprise et resynchronisation après trou de messages ;
+- late join ;
+- spectator éventuel ;
+- historique court/replay buffer lorsque nécessaire ;
+- validation anti-cheat des inputs/actions ;
+- séparation entre données persistantes et état éphémère de session ;
+- métriques, logs, traces et health du service temps réel ;
+- horizontal scaling, room placement et transfert/rehydration éventuel d'une session.
+
+### Synchronisation client associée
+
+Les capacités client correspondantes peuvent inclure :
+
+- buffer d'inputs ;
+- interpolation ;
+- extrapolation limitée ;
+- client-side prediction ;
+- reconciliation ;
+- rollback pour les genres qui le justifient ;
+- clock/tick synchronization ;
+- snapshot application ;
+- delta application ;
+- reconnect/resync state machine.
+
+Toutes ne sont pas nécessaires pour tous les jeux. Par exemple Snake à faible fréquence, racing et fighting n'ont pas les mêmes exigences de latence ni la même stratégie de synchronisation.
+
+### Chat et présence
+
+À séparer du gameplay realtime :
+
+- présence online/offline ;
+- chat lobby ;
+- chat de partie ;
+- modération ;
+- rate limiting ;
+- historique selon produit.
+
+Le déploiement peut commencer comme modular monolith, mais les responsabilités doivent rester séparables afin que le service realtime puisse évoluer indépendamment du Web/API classique.
+
+## Tooling candidates
+
+Besoins identifiés :
+
+- build Android multi-ABI ;
+- orchestration Desktop/Tauri/Web ;
+- packaging ;
+- génération de manifests produit ;
+- validation de dépendances/capabilities ;
+- génération de configuration logging ;
+- génération/validation assets ;
+- outils de map/level seulement lorsqu'un jeu concret en a besoin.
+
+## Hors réservation actuelle
+
+Ne sont pas réservés comme capacités du framework à ce stade :
+
+- rendu 3D ;
+- moteur physique 3D ;
+- VR/AR ;
+- voice chat ;
+- procedural world massif ;
+- scripting embarqué généraliste ;
+- plugin runtime dynamique par `.so`/`.dll` ;
+- marketplace générique ;
+- NFT.
+
+Ces sujets peuvent devenir des idées/études si un futur projet les justifie.

docs/studies/002-LAYERING_AND_OWNERSHIP_STUDY.md

@@ -0,0 +1,240 @@
+<!-- file: docs/studies/002-LAYERING_AND_OWNERSHIP_STUDY.md -->
+<!-- version: 1 -->
+
+# Étude du layering et de l'ownership
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+## Problème
+
+Le framework doit permettre plusieurs jeux et plateformes sans transformer `engine-v1` en monolithe ni multiplier prématurément les crates.
+
+Le classement proposé repose sur la question :
+
+> qui possède la règle et qui peut légitimement la réutiliser ?
+
+## 1. Engine kernel
+
+Responsabilités candidates :
+
+- lifecycle ;
+- temps/scheduling minimal ;
+- orchestration générique update/render ;
+- contrats minimaux entre runtime et jeu ;
+- provenance runtime ;
+- quit/lifecycle générique.
+
+Le kernel ne connaît pas :
+
+- score ;
+- vies ;
+- inventaire ;
+- ads ;
+- auth ;
+- leaderboard ;
+- maps propres au jeu ;
+- WebSocket ;
+- provider externe ;
+- règles Snake/Reflex.
+
+## 2. Technical capability
+
+Une technical capability fournit un service technique générique au jeu ou à un game-system.
+
+Exemples :
+
+- input ;
+- render ;
+- audio ;
+- assets ;
+- persistence ;
+- network transport ;
+- logging ;
+- identity client ;
+- ads client.
+
+Pattern candidat :
+
+```text
+capability API
+      ↑
+game / game-system
+      ↓
+adapter/provider implementation
+```
+
+Une capability n'impose pas qu'une crate existe immédiatement.
+
+## 3. Game-system
+
+Un game-system encapsule une mécanique de gameplay réutilisable.
+
+Exemples plausibles :
+
+- score ;
+- lives ;
+- energy ;
+- progression/XP ;
+- inventory ;
+- grid/tile map ;
+- collision simple ;
+- seeded challenge ;
+- puzzle primitives.
+
+Un game-system peut dépendre de capabilities techniques mais ne doit pas dépendre d'une app plateforme.
+
+Exemple :
+
+```text
+energy-system
+    ↓
+clock capability
+    ↓
+reward contract
+```
+
+Il ne doit pas appeler directement AdMob.
+
+## 4. Platform adapter
+
+Un adapter traduit une plateforme/backend vers une technical capability.
+
+Exemples :
+
+```text
+input-api
+  ├─ sdl-keyboard adapter
+  ├─ sdl-touch adapter
+  └─ web-pointer adapter
+```
+
+ou :
+
+```text
+render-api
+  ├─ sdl renderer
+  └─ web renderer
+```
+
+Un adapter peut être propre à une plateforme ou partagé par plusieurs plateformes lorsque le backend le permet.
+
+## 5. Provider
+
+Un provider intègre un service externe interchangeable.
+
+Exemples :
+
+- AdMob ;
+- Google OAuth ;
+- Play Games ;
+- Apple Game Center éventuel ;
+- backend leaderboards ;
+- CDN.
+
+Différence avec platform adapter :
+
+- adapter = traduit un environnement technique local ;
+- provider = parle à un service ou SDK externe pouvant être substitué.
+
+Un provider peut lui-même être platform-specific.
+
+## 6. Server service
+
+Le serveur possède les décisions qui ne peuvent pas être fiables côté client lorsqu'il existe un enjeu partagé ou compétitif.
+
+Exemples :
+
+- identité canonique ;
+- leaderboard validé ;
+- matchmaking ;
+- session realtime authoritative ;
+- récompense à valeur économique ;
+- résolution de conflits cloud ;
+- anti-cheat.
+
+Le client conserve les responsabilités locales nécessaires au fonctionnement offline lorsque le produit l'autorise.
+
+## 7. Game-specific
+
+La règle reste dans le jeu lorsque sa généralisation n'est pas démontrée.
+
+Exemples actuels :
+
+- croissance et corps du Snake ;
+- génération de séquence Reflex ;
+- règle exacte d'apparition/disparition des cibles ;
+- coût précis pour creuser une case dans un jeu d'aventure ;
+- moveset d'un personnage de fighting.
+
+Règle candidate :
+
+> un second besoin similaire peut justifier l'extraction d'un game-system ; un seul cas ne suffit pas automatiquement.
+
+## 8. Tooling
+
+Le tooling construit ou valide le produit mais n'entre pas dans le runtime du jeu.
+
+Exemples :
+
+- builder Android multi-ABI ;
+- packaging ;
+- génération de config ;
+- audit manifests/capabilities ;
+- outils de contenu.
+
+## Frontières proposées
+
+### À éviter
+
+```text
+game -> AdMob SDK
+game -> Java Android
+game -> Tauri command
+game -> tokio-tungstenite
+game -> filesystem OS direct
+```
+
+### Préféré
+
+```text
+game
+ ↓
+capability / game-system
+ ↓
+adapter/provider
+ ↓
+platform/external service
+```
+
+## API / façade / implémentation
+
+Lorsque la complexité le justifie, une famille peut suivre :
+
+```text
+<domain>-api
+<domain>-lib
+<domain>-<provider>-lib
+```
+
+Mais cette structure ne doit pas être créée par réflexe.
+
+Critères pour créer plusieurs crates :
+
+- plusieurs implémentations ;
+- besoin de dépendance inversée ;
+- frontière de compilation/platforme ;
+- dépendances lourdes que certains produits doivent éviter ;
+- tests/ownership clairement séparés.
+
+Sinon une seule crate réutilisable peut suffire.
+
+## Questions à trancher plus tard
+
+- `render` doit-il rester dans `engine-v1-sdl` ou devenir une capability explicite ?
+- `input` doit-il être un domaine autonome dès `0.2.x` ?
+- score/lives/energy doivent-ils être regroupés dans une crate `gameplay-common` ou rester séparés ?
+- grid/map/collision simple doivent-ils partager une famille de crates ?
+- networking doit-il être une technical capability ou une famille `networking/` distincte au workspace ?
+- où placer la frontière entre client auth générique et provider OAuth ?

docs/studies/003-PLATFORM_CAPABILITY_STUDY.md

@@ -0,0 +1,161 @@
+<!-- file: docs/studies/003-PLATFORM_CAPABILITY_STUDY.md -->
+<!-- version: 4 -->
+
+# Étude plateforme et disponibilité des capacités
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+## Axes indépendants
+
+Une cible produit ne doit pas être décrite par un seul enum « platform ».
+
+Axes candidats :
+
+### OS / environnement
+
+- Linux ;
+- Windows ;
+- macOS ;
+- Android ;
+- iOS ;
+- Browser/Web.
+
+### Device class
+
+- Desktop ;
+- Phone ;
+- Tablet ;
+- Unknown.
+
+D'autres classes ne sont ajoutées qu'avec un besoin réel.
+
+### Execution model
+
+- Native ;
+- Wasm.
+
+### Runtime host
+
+- Native ;
+- Browser ;
+- TauriWebView.
+
+### Backend
+
+Exemples actuels :
+
+- SDL3 ;
+- Web APIs via WASM ;
+- Tauri host + frontend Web/WASM.
+
+Le backend n'est pas l'identité du jeu.
+
+## Cibles connues
+
+| Cible               | OS/environnement    | Device               | Execution         | Host         | Backend principal  |
+|---------------------|---------------------|----------------------|-------------------|--------------|--------------------|
+| Desktop SDL Linux   | Linux               | Desktop              | Native            | Native       | SDL3               |
+| Desktop SDL Windows | Windows             | Desktop              | Native            | Native       | SDL3               |
+| Desktop SDL macOS   | macOS               | Desktop              | Native            | Native       | SDL3, réservé      |
+| Android SDL         | Android             | Phone/Tablet         | Native            | Native       | SDL3 + Java/JNI    |
+| iOS natif           | iOS                 | Phone/Tablet         | Native            | Native       | réservé            |
+| Web                 | Browser             | Desktop/Phone/Tablet | Wasm              | Browser      | Web/WASM           |
+| Tauri Desktop       | Linux/Windows/macOS | Desktop              | Wasm côté jeu POC | TauriWebView | Tauri + Web/WASM   |
+| Tauri Android       | Android             | Phone/Tablet         | à étudier         | TauriWebView | expérimental futur |
+
+## Capacités et variabilité
+
+### Input
+
+Desktop :
+
+- clavier ;
+- souris ;
+- gamepad éventuel.
+
+Mobile :
+
+- tactile ;
+- gestes ;
+- contrôles virtuels ;
+- gamepad éventuel.
+
+Web :
+
+- clavier/pointer/touch selon device ;
+- browser restrictions.
+
+Le mapping physique appartient à l'adapter/profil, pas au jeu.
+
+### Storage
+
+Native :
+
+- filesystem/app storage possible selon OS.
+
+Web :
+
+- stockage navigateur et quotas spécifiques.
+
+Le jeu doit consommer un contrat logique et non un chemin OS.
+
+### Ads et IAP
+
+Disponibilité dépendante du produit, de la plateforme et du provider.
+
+Un produit Desktop ou Web peut volontairement déclarer Ads `unsupported` ou `disabled` même si le framework possède une capability Ads.
+
+### Identity plateforme
+
+Play Games, Apple/Game Center ou services similaires sont des providers de plateforme. Aucun n'est requis pour définir un `PlayerId` canonique.
+
+### Networking
+
+HTTP/WebSocket sont plausibles sur toutes les grandes cibles mais leur implémentation et restrictions diffèrent.
+
+Le protocole métier reste indépendant du transport.
+
+Pour le multijoueur temps réel, le support d'un WebSocket côté plateforme ne suffit pas à définir la synchronisation. Le client doit pouvoir se connecter à une session distante qui possède ses propres contrats de tick, sequencing, snapshots/deltas, reconnexion et resynchronisation.
+
+Les contraintes navigateur/mobile/desktop peuvent modifier :
+
+- la durée de vie d'une connexion ;
+- la suspension en arrière-plan ;
+- les timeouts ;
+- les politiques de reconnexion ;
+- la disponibilité de threads/timers ;
+- les stratégies de buffering.
+
+Ces différences appartiennent aux adapters/runtime et ne doivent pas modifier le protocole de gameplay lui-même.
+
+## Politique de disponibilité candidate
+
+Une capability produit peut être :
+
+- `required` ;
+- `optional` ;
+- `disabled` ;
+- `unsupported` ;
+- `server-required`.
+
+Cette liste devra être challengée lors de l'étude du manifest produit.
+
+## SDL comme point d'entrée natif
+
+SDL3 est le backend natif de référence actuel parce qu'il permet de réutiliser une grande partie du runtime entre Desktop et Android et réserve une trajectoire macOS/iOS.
+
+Cette décision ne doit pas devenir :
+
+> tous les produits doivent obligatoirement utiliser SDL.
+
+Le POC Tauri Android servira précisément à comparer un second chemin de packaging/host sans modifier les règles de gameplay.
+
+## Questions ouvertes
+
+- support iOS : SDL natif seul, Tauri mobile, ou coexistence ?
+- rendu Web : abstraction SDL-like ou renderer Web dédié ?
+- gamepad mobile/web : capability immédiate ou réservation ?
+- filesystem et save-game : API unique avec garanties minimales ou contrats spécialisés ?
+- quelles capabilities doivent être détectables au runtime et lesquelles doivent être décidées au build ?

docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md

@@ -0,0 +1,195 @@
+<!-- file: docs/studies/004-GAME_ARCHETYPE_PRESSURE_TEST.md -->
+<!-- version: 3 -->
+
+# Pressure test par archétypes de jeux
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+Le but n'est pas de planifier tous ces jeux. Ils servent à vérifier que l'architecture envisagée ne fonctionne pas uniquement pour Reflex et Snake.
+
+## Reflex compétitif
+
+Besoins :
+
+- input pointer/touch ;
+- rendu 2D ;
+- timer précis ;
+- génération déterministe par seed/ruleset ;
+- score ;
+- leaderboard ;
+- auth optionnelle ou obligatoire selon mode ;
+- soumission de résultats ;
+- validation serveur potentielle.
+
+Conclusion provisoire :
+
+Reflex pousse surtout sur déterminisme, input abstrait, score et backend compétitif.
+
+## Snake configurable
+
+Besoins :
+
+- grid/tile map ;
+- input sémantique ;
+- sprites head/body/tail ;
+- obstacles ;
+- wrap/no-wrap ;
+- self-collision ;
+- plusieurs snakes ;
+- vitesse/ruleset configurable ;
+- maps ;
+- score/lives ;
+- bot/AI éventuel local ou serveur ;
+- multiplayer 2 joueurs éventuel.
+
+Conclusion provisoire :
+
+Snake est un bon candidat pour valider `grid`, `collision simple`, configuration de règles et séparation single-player/multiplayer.
+
+## Aventure puzzle à énergie
+
+Référence fonctionnelle : jeu d'exploration/puzzle avec énergie, cartes et mini-puzzles.
+
+Besoins :
+
+- map/tile ;
+- énergie ;
+- inventaire ;
+- progression/XP ;
+- niveaux/stages ;
+- save-game ;
+- account/cloud sync ;
+- rewarded ads ;
+- puzzle systems ;
+- leaderboard ou événements compétitifs éventuels ;
+- assets distants possibles.
+
+Conclusion provisoire :
+
+cet archétype exerce fortement les game-systems et services sans exiger du temps réel multijoueur.
+
+## Puzzle Sokoban / pipe / laser
+
+Besoins :
+
+- grid ;
+- occupancy ;
+- deterministic rules ;
+- undo/restart ;
+- map format ;
+- objectifs ;
+- éventuellement éditeur de niveaux.
+
+Conclusion provisoire :
+
+les puzzles doivent pouvoir partager des primitives sans transformer chaque règle en capability globale.
+
+## Racing 2–4 joueurs
+
+Besoins :
+
+- input faible latence ;
+- simulation ;
+- checkpoints/laps ;
+- interpolation/prediction éventuelle ;
+- matchmaking/lobby ;
+- session realtime ;
+- serveur authoritative pour compétition ;
+- tick serveur et sequencing des inputs ;
+- snapshots/deltas ;
+- interpolation et éventuellement prediction/reconciliation ;
+- reconnect/resync ;
+- spectator éventuellement ;
+- leaderboard.
+
+Conclusion provisoire :
+
+le networking temps réel doit rester séparé du kernel et du transport généraliste.
+
+## Fighting 1v1
+
+Besoins :
+
+- input précis ;
+- animation ;
+- hit/hurt boxes ;
+- health ;
+- move/state machine ;
+- rollback ou autre stratégie réseau si online compétitif ;
+- tick/frames synchronisés ;
+- input delay ou prediction selon modèle retenu ;
+- reconnect policy spécifique au match ;
+- matchmaking.
+
+Conclusion provisoire :
+
+l'architecture doit permettre un runtime spécialisé sans imposer ses contraintes de rollback à tous les jeux.
+
+## Hack'n slash
+
+Besoins :
+
+- map/collision ;
+- combat ;
+- inventory/equipment ;
+- progression ;
+- AI ;
+- save ;
+- online optionnel ou co-op selon produit.
+
+Conclusion provisoire :
+
+combat/inventory/progression doivent pouvoir être combinés sans appartenir au kernel.
+
+## MMORPG
+
+Besoins potentiels :
+
+- auth obligatoire ;
+- monde persistant ;
+- inventory/economy ;
+- serveur authoritative ;
+- gateway/session routing ;
+- zones/instances ;
+- interest management ;
+- snapshots/deltas et resynchronisation ;
+- chat ;
+- parties/guildes éventuelles ;
+- patch/assets distants ;
+- anti-cheat ;
+- observability serveur.
+
+Conclusion provisoire :
+
+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
+
+Besoins supplémentaires :
+
+- identité forte ;
+- wallet/provider isolé ;
+- reward authority ;
+- audit/anti-fraud ;
+- conformité et sécurité ;
+- séparation stricte entre gameplay et intégration crypto.
+
+Conclusion provisoire :
+
+la crypto n'est jamais une capability fondamentale du moteur. Elle appartient à un provider/service d'un produit spécifique.
+
+## Résultat du pressure test
+
+Le modèle semble devoir supporter au minimum :
+
+- kernel minimal ;
+- technical capabilities composables ;
+- game-systems réutilisables ;
+- adapters de plateforme ;
+- providers externes ;
+- services serveur ;
+- règles propres à chaque jeu.
+
+Aucun archétype étudié ne justifie à ce stade un engine monolithique contenant directement inventaire, ads, auth ou networking realtime.

docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md

@@ -0,0 +1,251 @@
+<!-- file: docs/studies/005-DEPENDENCY_AND_COMPOSITION_STUDY.md -->
+<!-- version: 5 -->
+
+# Étude des dépendances et de la composition
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2`.
+
+## Objectif
+
+Permettre qu'un produit choisisse uniquement ce dont il a besoin, sans duplication des jeux et sans couplage aux providers/platformes.
+
+## Dépendances proposées
+
+Direction générale :
+
+```text
+game-specific
+    ↓
+game-systems
+    ↓
+technical capability APIs
+    ↓
+engine kernel contracts
+```
+
+Les implémentations sont injectées/composées par le produit :
+
+```text
+app/product
+ ├─ game
+ ├─ adapters
+ ├─ providers
+ └─ runtime/backend
+```
+
+Le jeu ne choisit pas lui-même son provider AdMob, son adapter Android ou son transport concret.
+
+## Dépendances interdites candidates
+
+- kernel → game ;
+- kernel → provider ;
+- game-system → application plateforme ;
+- game → SDK publicitaire ;
+- game → Java Android ;
+- game → Tauri ;
+- provider → game-specific ;
+- serveur générique → crate d'application client.
+
+Des exceptions ne doivent être introduites qu'après justification explicite.
+
+## Composition statique
+
+La direction proposée reste la composition Rust statique.
+
+Exemple conceptuel :
+
+```text
+game-snake-android
+  ├─ game-snake
+  ├─ engine-v1-...
+  ├─ input-touch adapter
+  ├─ render-sdl adapter
+  ├─ logging-android
+  └─ ads-admob provider [si activé]
+```
+
+Un autre produit :
+
+```text
+game-snake-desktop
+  ├─ game-snake
+  ├─ engine-v1-...
+  ├─ input-keyboard adapter
+  ├─ render-sdl adapter
+  └─ no ads provider
+```
+
+Le gameplay reste le même.
+
+## Cargo features
+
+Les features Cargo restent utiles pour :
+
+- capacités locales d'une crate ;
+- optional dependencies ;
+- sélection technique bornée.
+
+Elles ne doivent pas devenir le langage global de composition du produit, car leur unification à travers le graphe peut rendre les variantes difficiles à raisonner.
+
+## Manifest produit/jeu
+
+Un manifest dédié pourra décrire plus tard :
+
+- engine generation ;
+- plateformes ;
+- capabilities requises ;
+- capabilities optionnelles ;
+- providers ;
+- online policy ;
+- input profiles ;
+- asset packs ;
+- logging profile.
+
+Exemple purement illustratif :
+
+```toml
+[product]
+game = "snake"
+engine = "v1"
+
+[capabilities]
+score = "required"
+auth = "optional"
+ads = "disabled"
+online = "optional"
+
+[platforms]
+desktop = true
+android = true
+web = true
+```
+
+Ce format n'est pas encore retenu.
+
+## Crates : création à la demande
+
+Un concept réservé n'entraîne pas automatiquement une crate.
+
+Créer une crate devient justifié notamment si :
+
+- plusieurs consommateurs réels existent ;
+- une dépendance lourde doit être isolée ;
+- plusieurs providers/adapters sont nécessaires ;
+- une frontière platform-specific est requise ;
+- un contrat stable mérite une API séparée.
+
+## Structure workspace candidate
+
+La structure pourrait évoluer vers des familles comme :
+
+```text
+crates/
+  engines/
+  capabilities/
+  game-systems/
+  providers/
+  networking/
+  games/
+  apps/
+  servers/
+  common/
+  tools/
+```
+
+Cette arborescence est une hypothèse d'étude. Elle n'est pas encore un contrat de fichiers.
+
+## Realtime : séparation des responsabilités
+
+Le temps réel ne doit pas être représenté par une seule capability `websocket`.
+
+Découpage candidat :
+
+```text
+transport
+    ↓
+wire protocol / message codec
+    ↓
+session protocol
+    ↓
+synchronization strategy
+    ↓
+game-specific authoritative simulation
+```
+
+Responsabilités :
+
+- **transport** — connexion, frames, timeout, reconnexion bas niveau ;
+- **wire protocol** — envelope, version, message ids, serialization ;
+- **session protocol** — join/leave/start/end, identity/session ids, heartbeat ;
+- **synchronization strategy** — tick, input stream, snapshots, deltas, acknowledgement, resync ;
+- **game-specific simulation** — validation des inputs et évolution authoritative du monde selon les règles du jeu.
+
+Le framework peut fournir les couches techniques réutilisables sans imposer une simulation générique identique à Snake, Racing ou Fighting.
+
+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 :
+
+- offline-only ;
+- online-optional ;
+- online-required ;
+- online-required pour une capability particulière.
+
+Un jeu online-optional ne doit pas avoir à compiler tout un stack realtime s'il n'en a pas besoin.
+
+## Étape suivante après validation de l'étude
+
+Après revue de `0-pre.2`, les décisions retenues pourront être promues progressivement vers `docs/architecture/`.
+
+Ce n'est qu'après cette promotion qu'il sera pertinent de planifier les POC techniques, notamment Tauri Android, Web/WASM et les variantes natives, pour tester les hypothèses de plateforme.

docs/studies/006-REALTIME_MULTIPLAYER_SERVER_STUDY.md

@@ -0,0 +1,321 @@
+<!-- file: docs/studies/006-REALTIME_MULTIPLAYER_SERVER_STUDY.md -->
+<!-- version: 1 -->
+
+# Étude serveur multijoueur temps réel
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.2.fix.1`.
+
+Ce document complète l'inventaire initial. Il ne choisit pas encore une stack serveur, un crate WebSocket ou une fréquence de tick unique.
+
+## Objectif
+
+Séparer clairement :
+
+- transport réseau ;
+- protocole de session ;
+- synchronisation d'état ;
+- simulation authoritative ;
+- services Web persistants.
+
+Un WebSocket fournit un canal bidirectionnel ; il ne résout pas à lui seul la synchronisation multijoueur.
+
+## Plan de contrôle et plan de données
+
+### Control plane
+
+Responsabilités plausibles :
+
+- authentification ;
+- matchmaking ;
+- création/allocation de partie ;
+- roster ;
+- invitation/join/leave ;
+- ready/start/end ;
+- sélection d'une instance realtime ;
+- reprise de session.
+
+Ces opérations peuvent passer par HTTP(S), WebSocket ou une combinaison, sans être exécutées dans la boucle de simulation.
+
+### Realtime data plane
+
+Responsabilités plausibles :
+
+- accepter les connexions de joueurs ;
+- associer connexion, joueur et session ;
+- recevoir les inputs/commands ;
+- sequencer les messages ;
+- maintenir le tick/cycle de simulation ;
+- faire évoluer l'état authoritative ;
+- diffuser snapshots et deltas ;
+- détecter pertes/timeouts ;
+- gérer reconnexion et resynchronisation ;
+- appliquer backpressure/rate limits ;
+- produire observability et health.
+
+## Modèles de synchronisation
+
+Aucun modèle unique ne convient à tous les jeux.
+
+### Input authoritative
+
+Le client envoie principalement ses inputs.
+
+Le serveur :
+
+1. valide l'input ;
+2. l'applique à la simulation ;
+3. avance l'état ;
+4. publie l'état ou son delta.
+
+Approprié à de nombreux jeux compétitifs.
+
+### State replication
+
+Le serveur publie :
+
+- snapshots périodiques ;
+- deltas entre snapshots ;
+- revision/tick associé ;
+- éventuellement ack/last-applied revision.
+
+Le client reconstruit un état local de présentation.
+
+### Prediction / reconciliation
+
+Pour réduire la latence perçue :
+
+- le client prédit localement ;
+- conserve les inputs non confirmés ;
+- reçoit l'état serveur ;
+- corrige/rejoue si nécessaire.
+
+À réserver aux jeux qui en ont besoin.
+
+### Rollback
+
+Particulièrement pertinent pour certains jeux de combat :
+
+- historique court d'états ;
+- inputs retardés ou prédits ;
+- rollback/re-simulation.
+
+Ce modèle ne doit pas contaminer le runtime de tous les jeux.
+
+## Contrats techniques candidats
+
+### Envelope réseau
+
+Champs conceptuels possibles :
+
+- protocol version ;
+- message type ;
+- session id ;
+- player id/connection id si nécessaire ;
+- sequence ;
+- server tick ;
+- client tick/time ;
+- payload.
+
+Le format exact n'est pas encore décidé.
+
+### Snapshot
+
+Doit permettre :
+
+- état complet cohérent ;
+- revision/tick ;
+- application atomique côté client ;
+- point de reprise après resync.
+
+### Delta
+
+Doit préciser :
+
+- base revision ;
+- target revision ;
+- mutations ;
+- comportement si la base manque.
+
+Un delta manquant doit conduire à une resynchronisation contrôlée, pas à une divergence silencieuse.
+
+## Reconnexion et resynchronisation
+
+Cas à traiter :
+
+- coupure courte ;
+- suspension mobile ;
+- changement de réseau ;
+- client trop en retard ;
+- trou dans les séquences ;
+- restart d'une instance serveur.
+
+États conceptuels possibles :
+
+```text
+Disconnected
+Connecting
+Joining
+Synchronized
+Resynchronizing
+Leaving
+```
+
+Le jeu ne doit pas confondre « socket ouvert » et « état de gameplay synchronisé ».
+
+## Rooms, instances et scaling
+
+Pour plusieurs parties simultanées :
+
+- une room/session possède une autorité unique à un instant donné ;
+- les connexions sont routées vers l'instance responsable ;
+- l'instance peut héberger plusieurs rooms selon charge ;
+- la distribution des rooms peut évoluer indépendamment du protocole client ;
+- les données persistantes ne doivent pas être écrites dans la DB à chaque tick sans nécessité.
+
+À plus grande échelle, il faudra étudier :
+
+- session placement ;
+- shard/region ;
+- sticky routing ;
+- handoff/migration ;
+- recovery après crash ;
+- autoscaling ;
+- limites par instance.
+
+## Interest management
+
+Pour un petit Snake 2 joueurs, diffuser tout l'état peut être acceptable.
+
+Pour une map plus grande/MMORPG, il faut pouvoir limiter les données à :
+
+- zone visible ;
+- proximité ;
+- équipe ;
+- objets pertinents ;
+- fréquence adaptée au type d'entité.
+
+L'interest management appartient au service realtime/game server, pas au renderer client.
+
+## Persistence
+
+Séparer :
+
+### État éphémère
+
+- positions ;
+- velocities ;
+- animation/state machine ;
+- projectiles ;
+- tick courant.
+
+### État durable
+
+- compte ;
+- progression ;
+- inventory ;
+- résultat de match ;
+- rewards ;
+- classement.
+
+Le durable est persisté à des frontières métier appropriées, pas mécaniquement à chaque frame.
+
+## Sécurité / anti-cheat
+
+Principes candidats :
+
+- ne pas faire confiance à une position envoyée directement par un client compétitif ;
+- valider les actions et contraintes de jeu côté serveur ;
+- rate limit ;
+- protéger join/session tokens ;
+- empêcher replay/double-submit d'actions sensibles ;
+- enregistrer suffisamment de données pour diagnostiquer une divergence ou fraude.
+
+## Observability
+
+Le realtime nécessite au minimum des dimensions dédiées :
+
+- connexions actives ;
+- rooms actives ;
+- joueurs/session ;
+- tick duration ;
+- tick lag ;
+- queue/backpressure ;
+- messages/s ;
+- bytes/s ;
+- reconnects ;
+- resyncs ;
+- dropped/invalid inputs ;
+- snapshot/delta sizes ;
+- errors par protocole/version.
+
+Le logging par domaines devra pouvoir distinguer transport, session, sync et simulation.
+
+## Technologies
+
+Le choix exact reste volontairement ouvert.
+
+Candidats à étudier ultérieurement selon le POC serveur :
+
+- HTTP(S) pour control plane/API ;
+- WebSocket pour data plane bidirectionnel ;
+- gRPC pour backend-to-backend ou services structurés ;
+- WebRTC uniquement si un besoin P2P/media le justifie.
+
+Le framework ne doit pas imposer une technologie unique à tous les services.
+
+## Pressure test rapide
+
+### Snake 2 joueurs
+
+Peut probablement fonctionner avec :
+
+- tick modéré ;
+- inputs directionnels ;
+- état authoritative ;
+- snapshot/delta simple ;
+- interpolation limitée ;
+- reconnect/resync.
+
+### Racing
+
+Exigera potentiellement :
+
+- tick plus fréquent ;
+- prediction/reconciliation ;
+- interpolation ;
+- lag compensation selon gameplay ;
+- snapshots/deltas optimisés.
+
+### Fighting 1v1
+
+Peut nécessiter :
+
+- input synchronization très stricte ;
+- rollback netcode ou stratégie équivalente ;
+- historique court déterministe.
+
+### MMORPG
+
+Exigera potentiellement :
+
+- zones/shards ;
+- interest management ;
+- sessions longues ;
+- persistence structurée ;
+- chat/presence ;
+- recovery/scaling.
+
+## Questions ouvertes pour le futur POC serveur
+
+- Axum + Tokio + WebSocket suffit-il pour le premier service realtime ?
+- Une room est-elle une task, un actor, un shard ou une structure pilotée par scheduler ?
+- Quelle cadence de tick pour chaque genre ?
+- Quel codec : JSON de debug, bincode/postcard/protobuf/autre en production ?
+- Quelle frontière entre types de protocole partagés et logique serveur ?
+- Comment versionner le protocole sans coupler toutes les apps ?
+- Comment tester déterminisme, perte de paquets logique, reconnexion et resync ?
+- Quand introduire Redis/NATS/Kafka ou autre coordination, si jamais nécessaire ?
+
+Ces choix appartiennent à la future planification/POC, pas à cette étude de réservation.

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 ?

docs/studies/009-PLATFORM_POC_CANDIDATES.md

@@ -0,0 +1,231 @@
+<!-- file: docs/studies/009-PLATFORM_POC_CANDIDATES.md -->
+<!-- version: 2 -->
+
+# 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 Snake
+
+### Question
+
+Le chemin Tauri Android peut-il exécuter le gameplay Snake avec une intégration mobile acceptable, en réutilisant au maximum les briques déjà validées par le POC Tauri/WASM Reflex ?
+
+### Réutilisation visée
+
+- `game-snake-poc` ;
+- abstractions et bridge Tauri/WASM déjà validés avec Reflex, après généralisation minimale ;
+- 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 Snake
+
+### Question
+
+Le gameplay Snake peut-il être livré comme jeu Web direct, sans Tauri, avec un packaging propre et un input clavier/tactile fiable ?
+
+### Réutilisation visée
+
+- `game-snake-poc` ;
+- adaptation/généralisation de la 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 peut-elle être généralisée proprement pour Snake sans duplication structurelle ?
+
+### 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
+
+Snake, afin de conserver le même jeu-sonde sur toutes les plateformes.
+
+### À 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 ;
+- 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 autour du même gameplay Snake :
+
+```text
+SDL native
+Web/WASM
+Tauri/WebView
+```
+
+sur plusieurs hosts sans modifier le gameplay.

docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md

@@ -0,0 +1,91 @@
+<!-- file: docs/studies/010-PLATFORM_POC_REUSE_AND_DELTA.md -->
+<!-- version: 2 -->
+
+# 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.
+
+## Snake comme sonde unique des POC plateforme
+
+Snake devient le jeu-sonde de référence pour les POC plateforme de la future série `0.3.x`.
+
+Il exerce simultanément :
+
+- keyboard/swipe/touch ;
+- update continu ;
+- grille et déplacements ;
+- plusieurs entités ;
+- état de jeu persistant ;
+- obstacles/collision ;
+- score/lives potentiels ;
+- resize/orientation ;
+- besoin potentiel de virtual controls ;
+- future extension multi-snake/multiplayer.
+
+Les briques Tauri/WASM déjà construites avec Reflex restent des références techniques à réutiliser, mais les nouveaux POC ne doivent plus utiliser Reflex comme jeu principal.
+
+## 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.

docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md

@@ -0,0 +1,53 @@
+<!-- file: docs/studies/011-PLATFORM_POC_VALIDATION_MATRIX.md -->
+<!-- version: 3 -->
+
+# 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               | grille/Snake visibles, multi-entités, resize/orientation          |
+| Input                | Snake : directions, keyboard/swipe/touch, latence perçue          |
+| 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 `game-snake-poc`, adapters et 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.

docs/studies/012-PLATFORM_POC_SEQUENCE.md

@@ -0,0 +1,72 @@
+<!-- file: docs/studies/012-PLATFORM_POC_SEQUENCE.md -->
+<!-- version: 2 -->
+
+# 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 + Snake ;
+2. Web navigateur direct + Snake ;
+3. Tauri Desktop + Snake ;
+4. builder Android multi-ABI centré sur Snake.
+
+Raisons :
+
+- un seul gameplay de référence sur toutes les plateformes ;
+- réutilisation maximale de `game-snake-poc` ;
+- environnement déjà proche de celui utilisé ;
+- comparaison directe SDL / Web / Tauri ;
+- préparation directe du futur super Snake ;
+- 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.

docs/studies/013-UROBURAS_FUNCTIONAL_SPEC.md

@@ -0,0 +1,149 @@
+<!-- file: docs/studies/013-UROBURAS_FUNCTIONAL_SPEC.md -->
+<!-- version: 2 -->
+
+# Uroburas — spécification fonctionnelle initiale
+
+## Statut
+
+Étude fonctionnelle non normative pour `0.2.0-0-pre.5`.
+
+Cette prerelease décrit le comportement attendu. Le classement par engine, capability, game-system, serveur, provider, plateforme ou tooling est volontairement reporté.
+
+## Identité
+
+Nom retenu : `Uroburas`.
+
+Uroburas est un Snake extensible comportant plusieurs modes, des cartes téléchargeables, des règles configurables, du solo, du PvP et un monde persistant multijoueur.
+
+## Client installé
+
+Le client installé contient principalement :
+
+- moteur/runtime ;
+- logique de jeu partagée ;
+- interfaces/loaders ;
+- support plateforme ;
+- ressources minimales de bootstrap.
+
+Les cartes, assets et contenus associés peuvent être téléchargés séparément.
+
+Le client ne doit pas supposer que toutes les maps ou tous les assets existent lors de l'installation.
+
+## Anatomie minimale du serpent
+
+Un serpent valide possède au minimum quatre unités logiques :
+
+1. une tête ;
+2. un cou ;
+3. une unité de corps ;
+4. une queue.
+
+Seul le **corps** est extensible.
+
+La longueur ne peut donc jamais devenir inférieure à quatre unités. Une attaque ou un effet de rétrécissement ne peut pas supprimer la tête, le cou, l'unité minimale de corps ou la queue en dehors d'une règle de mort explicite.
+
+Les interactions peuvent produire des effets différents selon la zone touchée.
+
+## Gameplay attendu
+
+Le jeu doit permettre :
+
+- croissance et rétrécissement ;
+- coupure du corps ;
+- déplacement continu ou par pas selon la map ;
+- wrap-around aux bords lorsqu'autorisé ;
+- obstacles infranchissables ;
+- éléments à manger ;
+- éléments poussables ;
+- items temporaires ;
+- protections ;
+- projectiles/effets offensifs ;
+- timers ;
+- spawns et respawns.
+
+## Règles pilotées par la map
+
+Une map peut définir ou contraindre :
+
+- taille et topology/wrap ;
+- murs/obstacles ;
+- spawn points ;
+- mode de déplacement ;
+- vitesse initiale et évolution ;
+- vies ;
+- items disponibles ;
+- objectifs ;
+- conditions de victoire/défaite ;
+- équipes ;
+- bots ;
+- spectator ;
+- timers ;
+- score ;
+- paramètres PvP.
+
+## Modes
+
+Trois modes principaux :
+
+1. Challenge ;
+2. PvP Battles ;
+3. Persistent Battle Royale.
+
+## Online et identité
+
+Le mode Challenge peut être joué sans authentification.
+
+Les modes PvP Battles et Persistent Battle Royale exigent réseau et authentification.
+
+## Personnalisation future
+
+Le produit vise aussi :
+
+- éditeur de maps ;
+- maps personnalisées ;
+- skins personnalisables ;
+- publication/modération éventuelles.
+
+## Représentation graphique du serpent
+
+La représentation doit pouvoir limiter le nombre d'assets nécessaires grâce aux rotations d'image.
+
+Direction fonctionnelle envisagée :
+
+- tête, cou, segments droits et queue peuvent réutiliser leurs sprites par rotation ;
+- les virages du corps nécessitent au minimum deux variantes distinctes correspondant à une courbure vers la gauche et vers la droite relativement au mouvement ;
+- ces variantes peuvent ensuite être réutilisées par rotation ;
+- les skins doivent respecter le même contrat géométrique afin d'être interchangeables.
+
+Le détail du format de skin sera défini séparément.
+
+## Priorité de la première version Uroburas
+
+La première version réelle de Uroburas se concentre sur le **Mode 1 — Challenge**.
+
+Elle doit prioritairement permettre :
+
+- moteur de grille/tilemap toroïdale ;
+- obstacles et murs ;
+- items ;
+- vies ;
+- temps ;
+- stages ;
+- caméra sur maps plus grandes que l'écran ;
+- contrôles clavier Desktop ;
+- contrôles tactiles par boutons directionnels affichés sur Mobile/Tablet ;
+- site Web initial ;
+- authentification ;
+- rewarded ads ;
+- Hall of Fame initial ;
+- échanges client/serveur authentifiés, versionnés et validables ;
+- maps/assets téléchargeables.
+
+Les systèmes de combat avancés feu/glace/poison/téléporteurs restent décrits comme direction fonctionnelle, mais ne sont pas requis pour cette première version.
+
+L'ordre de développement fonctionnel envisagé après stabilisation du Mode 1 est :
+
+1. Mode 3 — Persistent Battle Royale ;
+2. Mode 2 — PvP Battles.
+
+Cet ordre peut être réévalué ultérieurement, mais sert de priorité actuelle.

docs/studies/014-UROBURAS_MODES_AND_SESSION_RULES.md

@@ -0,0 +1,164 @@
+<!-- file: docs/studies/014-UROBURAS_MODES_AND_SESSION_RULES.md -->
+<!-- version: 2 -->
+
+# Uroburas — modes et règles de session
+
+## Mode 1 — Challenge
+
+### Accès
+
+- jouable sans authentification ;
+- réseau non requis pour jouer ;
+- réseau/auth requis pour Hall of Fame et rewarded ads lorsque utilisés.
+
+### Run
+
+Une run :
+
+- commence au stage 1 ;
+- commence au spawn défini ;
+- démarre avec un nombre initial de vies ;
+- progresse à travers les stages ;
+- se termine à l'abandon, à la fin prévue ou lorsque plus aucune continuation n'est disponible.
+
+### Mort
+
+Lorsqu'un joueur meurt :
+
+- il perd une vie ;
+- il respawn au spawn du stage ;
+- l'état exact du stage après mort est défini par la map/ruleset.
+
+À zéro vie, une rewarded ad peut éventuellement offrir une continuation si réseau et monétisation sont disponibles.
+
+Pendant la transition entre deux stages, une rewarded ad peut aussi proposer une récompense optionnelle, par exemple doubler les points gagnés pour le stage terminé. La règle exacte et le multiplicateur restent configurables.
+
+### Contrôles
+
+Sur Desktop, le jeu peut utiliser des touches directionnelles physiques, notamment WASD et/ou les flèches selon configuration.
+
+Sur Mobile/Tablet, la première approche privilégiée est un pavé directionnel affiché à l'écran, fonctionnellement équivalent à des touches directionnelles/WASD. Le joueur appuie sur les boutons plutôt que d'utiliser principalement des swipes.
+
+Ce choix vise à conserver une logique de contrôle proche entre Desktop et Mobile/Tablet.
+
+### Stage
+
+Une map Challenge peut :
+
+- dépasser l'écran ;
+- être wrap-around ;
+- contenir murs/obstacles ;
+- contenir objectifs à consommer ;
+- contenir objets poussables ;
+- faire grandir/rétrécir ;
+- faire apparaître vies/items temporairement ;
+- utiliser déplacement step-based ou auto-forward ;
+- faire varier la vitesse.
+
+## Mode 2 — PvP Battles
+
+### Accès
+
+- réseau obligatoire ;
+- authentification obligatoire.
+
+### Participants
+
+La partie peut supporter :
+
+- 1v1 ;
+- 3 joueurs ;
+- 4 joueurs ;
+- équipes ;
+- free-for-all ;
+- bots si autorisés.
+
+### Création et sélection
+
+Une partie peut être :
+
+- privée ;
+- réservée à des joueurs présélectionnés ;
+- ouverte à matchmaking/aléatoire ;
+- composée de joueurs et bots.
+
+Les participants peuvent choisir une map selon les règles de la session.
+
+### Règles
+
+La map/ruleset peut définir :
+
+- nombre de vies ;
+- items ;
+- collisions ;
+- équipes ;
+- conditions de victoire ;
+- spectator ;
+- bots ;
+- timers ;
+- vitesse ;
+- autres paramètres.
+
+### Fin
+
+La session finit lorsque la condition de victoire est satisfaite.
+
+Exemples : dernier joueur vivant, dernière équipe vivante, épuisement des vies, score cible ou limite de temps.
+
+## Mode 3 — Persistent Battle Royale
+
+### Accès
+
+- réseau obligatoire ;
+- authentification obligatoire pour jouer ;
+- observation possible selon politique serveur.
+
+### Monde
+
+Une map :
+
+- peut être gigantesque ;
+- reste active jusqu'à décision administrative ;
+- accepte joueurs entrant/sortant ;
+- contient bots serveur et items temporaires ;
+- peut être découpée en zones/chunks.
+
+### Tentative
+
+Chaque entrée active constitue une tentative.
+
+Le joueur :
+
+- spawn sur un point valide ;
+- possède une vie ;
+- commence score/progression de tentative à zéro ;
+- peut tuer joueurs ou bots ;
+- peut être tué par joueurs, bots, environnement ou effets.
+
+### Mort et retour
+
+À la mort :
+
+- la tentative est close ;
+- l'ancien état n'est pas restauré ;
+- le joueur attend avant de revenir, par exemple sept minutes ;
+- une rewarded ad peut réduire/supprimer l'attente ;
+- le retour démarre une nouvelle tentative à zéro.
+
+### Bots
+
+Les bots sont exécutés côté serveur, peuvent mourir, respawn après un délai et recevoir un nouveau profil comportemental à chaque respawn.
+
+### Observation
+
+Un utilisateur peut rester spectateur sans tentative active.
+
+## Priorité de développement des modes
+
+L'implémentation réelle doit d'abord stabiliser les moteurs et besoins du Mode 1.
+
+Le Mode 3 vient ensuite afin d'ajouter progressivement le temps réel persistant, les bots serveur et les règles de monde longue durée sur une base de gameplay déjà stable.
+
+Le Mode 2 vient ensuite afin de construire les parties PvP bornées, privées ou matchmaking, en réutilisant les mécanismes multijoueurs déjà éprouvés.
+
+La présence de la spec des Modes 2 et 3 dans `0.2.0` n'implique pas leur implémentation dans la première version Uroburas.

docs/studies/015-UROBURAS_MAP_ASSET_AND_UGC_SPEC.md

@@ -0,0 +1,65 @@
+<!-- file: docs/studies/015-UROBURAS_MAP_ASSET_AND_UGC_SPEC.md -->
+<!-- version: 2 -->
+
+# Uroburas — maps, assets et UGC
+
+## Contenu embarqué et téléchargement
+
+Le package du jeu peut embarquer les maps solo initiales et les assets nécessaires à la première expérience.
+
+Le client doit néanmoins pouvoir télécharger ou mettre à jour :
+
+- maps supplémentaires ;
+- skins ;
+- textures/sprites ;
+- sons ;
+- metadata ;
+- rulesets ;
+- autres ressources propres à une map ou à une saison/version.
+
+Le téléchargement de contenu est donc une fonction normale du produit, pas uniquement une extension UGC.
+
+## Package de map
+
+Une map publiée peut référencer :
+
+- map id/version ;
+- game/ruleset compatibility ;
+- tilemap ;
+- dimensions ;
+- topology/wrap ;
+- layers ;
+- obstacles ;
+- spawn points ;
+- item/bot spawn rules ;
+- objectives ;
+- timers ;
+- rules ;
+- asset manifest.
+
+## Règles par map
+
+Une map peut fixer notamment déplacement, vitesse, vies, équipes, bots, spectator, items, puissance des items, score, fin de partie, respawn et cooldowns.
+
+## Cache et compatibilité
+
+Le client doit pouvoir découvrir une map, vérifier compatibilité/version/intégrité, télécharger package/assets, mettre en cache et remplacer une version obsolète.
+
+## Éditeur de maps
+
+Objectifs :
+
+- créer map ;
+- placer obstacles/spawns/objectifs/items ;
+- configurer règles ;
+- tester localement ;
+- sauvegarder draft ;
+- publier si autorisé.
+
+## UGC
+
+Une map utilisateur peut avoir auteur, id/version, visibilité, état draft/published, description/tags, rating, reports, moderation status et compatibility metadata.
+
+## Skins
+
+Première approche possible : palettes, motifs, variantes tête/corps/queue et accessoires autorisés. L'upload libre d'images reste séparé.

docs/studies/016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md

@@ -0,0 +1,82 @@
+<!-- file: docs/studies/016-UROBURAS_COMBAT_ITEM_EFFECT_SPEC.md -->
+<!-- version: 2 -->
+
+# Uroburas — combat, items et effets
+
+## Principe
+
+Une attaque peut produire un résultat différent selon tête, cou, corps ou queue. Une attaque peut parfois devenir indirectement bénéfique en raccourcissant le serpent.
+
+Le serpent ne peut toutefois jamais être raccourci sous son anatomie minimale : tête + cou + une unité de corps + queue. Les effets qui devraient supprimer davantage de segments sont bornés à cette longueur minimale, sauf si l'impact constitue une mort explicite.
+
+## Inventaire
+
+Un serpent peut obtenir un ou plusieurs items et décider de les utiliser ou non. Capacité, stacking, puissance, durée, cooldown et combinaison sont configurables par ruleset.
+
+## Boule de feu
+
+### Tête non protégée
+
+- tue le serpent.
+
+### Tête protégée
+
+- consomme un ou plusieurs points de casque selon puissance ;
+- peut tuer si la protection est insuffisante.
+
+### Corps / queue
+
+- détruit ou coupe une portion selon niveau/puissance ;
+- peut raccourcir le serpent et parfois l'avantager.
+
+## Boule de glace
+
+### Tête non protégée
+
+- peut tuer.
+
+### Tête avec casque
+
+- consomme un ou plusieurs points de protection ;
+- peut geler le serpent pendant une durée ;
+- le gel peut entraîner un rétrécissement du corps.
+
+### Corps non protégé
+
+- coupe la portion concernée.
+
+### Corps protégé par shield
+
+- peut geler temporairement la portion ;
+- peut modifier temporairement croissance/longueur ;
+- les détails dépendent du ruleset.
+
+## Poison
+
+Le poison peut être projeté depuis la tête, parcourir un nombre limité de cases, se propager pendant une durée, contaminer plusieurs tiles puis disparaître.
+
+Sur la tête il peut tuer selon protection/ruleset. Sur le corps il peut couper à l'endroit atteint et donc raccourcir le serpent.
+
+## Casque / masque
+
+Protection de tête avec plusieurs points possibles, cumul via pickups et absorption de plusieurs coups selon puissance.
+
+## Body shield
+
+Le shield protège le corps à partir du cou. Chaque portion protégée peut perdre sa protection individuellement.
+
+## Téléporteurs
+
+Les téléporteurs peuvent fonctionner par paire ou groupe, utiliser un identifiant/canal, être temporaires/permanents et être placés par map ou activés par item.
+
+## Paramétrage
+
+Les effets peuvent définir level, power, range, duration, spread, cooldown, zone, charges et interactions avec protections.
+
+## Portée de la première version
+
+Feu, glace, poison, téléporteurs et protections avancées restent dans la spécification afin de préserver la direction du game design.
+
+Ils ne sont pas requis pour la première version réelle, centrée sur le Mode 1 et ses moteurs fondamentaux.
+
+Leur modélisation détaillée pourra être revue avant l'implémentation des modes multijoueurs.

docs/studies/017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md

@@ -0,0 +1,32 @@
+<!-- file: docs/studies/017-UROBURAS_SCORE_RESPAWN_AND_HALL_OF_FAME.md -->
+<!-- version: 2 -->
+
+# Uroburas — score, respawn et Hall of Fame
+
+## Challenge
+
+Une run peut enregistrer points, temps, stage atteint, vies restantes, morts, continues et rewarded continues.
+
+Le score peut combiner score brut, bonus, pénalités de mort, pénalités de continue et pénalités de rewarded continue.
+
+## Hall of Fame Challenge
+
+Si le joueur est online/authentifié lorsqu'il termine ou quitte, points, temps, stage, morts/continues et versions de map/ruleset/game peuvent être soumis.
+
+## PvP
+
+Le résultat peut inclure winner/team, kills/deaths, vies consommées, durée, map/ruleset et composition joueurs/bots.
+
+## Battle Royale
+
+Chaque tentative repart de zéro. Statistiques candidates : survival time, player kills, bot kills, maximum length, items, distance et cause of death.
+
+## Respawn / rejoin
+
+Joueur : une vie par tentative, cooldown de retour, rewarded ad possible, rejoin = nouvelle tentative.
+
+Bot : respawn automatique, délai plus court, profil comportemental éventuellement renouvelé.
+
+## Comparabilité
+
+Un score conserve mode, map id/version, ruleset version, game version et seed si applicable.

docs/studies/018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md

@@ -0,0 +1,34 @@
+<!-- file: docs/studies/018-UROBURAS_SERVER_MEDIA_AND_OBSERVATION_SPEC.md -->
+<!-- version: 1 -->
+
+# Uroburas — observation, bots et média serveur
+
+## Spectator
+
+Les modes online peuvent autoriser suivi d'un joueur, changement de joueur, vue de zone, vue libre limitée et leaderboard/live stats. La politique peut être désactivée, limitée ou retardée.
+
+## PvP
+
+Le spectator peut être activé/désactivé, limité à certains utilisateurs, autorisé après élimination ou différé pour éviter le ghosting.
+
+## Battle Royale
+
+Un utilisateur peut rester observateur pendant le cooldown ou sans jouer.
+
+## Reconstitution serveur
+
+Le serveur authoritative possède les données nécessaires pour produire une représentation indépendante d'un client joueur.
+
+Objectifs futurs : replay, observation Web, streaming, enregistrement, génération de vidéo et publication sur plateformes vidéo.
+
+## Vidéo régénérée
+
+Une stratégie possible consiste à enregistrer événements/états puis reconstruire la partie dans un processus dédié afin de choisir caméra/angle et produire vidéo ou stream. Une autre stratégie est un renderer serveur/headless spécialisé.
+
+Aucune technologie n'est choisie ici.
+
+## Données candidates
+
+Snapshots, event log, inputs/actions, positions, item usage, deaths/kills, spawn/despawn, map/ruleset version et timestamps/ticks.
+
+Le service media ne doit pas appartenir à la boucle critique de simulation.

docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md

@@ -0,0 +1,410 @@
+<!-- file: docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md -->
+<!-- version: 2 -->
+
+# Uroburas — classification fonctionnelle par ownership
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.6`.
+
+Objectif : éviter que les futures crates Uroburas multiplateformes deviennent des monolithes contenant des responsabilités réutilisables, serveur, plateforme ou tooling.
+
+## Principe
+
+Une fonctionnalité appartient à la couche la plus basse qui puisse la fournir sans connaître Uroburas.
+
+La crate jeu conserve uniquement :
+
+- règles propres à Uroburas ;
+- composition des game-systems ;
+- contenu/rulesets Uroburas ;
+- coordination propre aux modes.
+
+## Engine kernel
+
+Responsabilités minimales :
+
+- lifecycle générique ;
+- boucle update/render ;
+- temps monotone ;
+- fixed-step/scheduling si retenu ;
+- runtime events ;
+- provenance runtime ;
+- contrats minimaux input/render ;
+- quit/pause génériques.
+
+Le kernel ne connaît pas :
+
+- Snake ;
+- stages ;
+- vies ;
+- Hall of Fame ;
+- publicité ;
+- auth ;
+- maps Uroburas ;
+- WebSocket ;
+- Actix.
+
+## Technical capabilities
+
+### Input
+
+- semantic actions ;
+- keyboard ;
+- virtual buttons tactiles ;
+- gamepad éventuel ;
+- mapping/configuration ;
+- focus/lifecycle input.
+
+### Rendering 2D
+
+- sprites/textures ;
+- rotation ;
+- viewport ;
+- caméra 2D ;
+- layers/z-order ;
+- animation sprite simple ;
+- debug primitives.
+
+### Audio
+
+- musique ;
+- SFX ;
+- volume/mute ;
+- lifecycle audio.
+
+### Assets/content
+
+- asset identifiers ;
+- package manifest ;
+- téléchargement ;
+- cache ;
+- version/intégrité ;
+- invalidation ;
+- résolution de chemins logiques.
+
+### Localization
+
+- locales ;
+- Fluent resources ;
+- fallback ;
+- message arguments ;
+- bundles client ;
+- ressources localisées téléchargées.
+
+### Persistence locale
+
+- settings ;
+- cache ;
+- progression locale éventuelle ;
+- données de session offline.
+
+### Networking client
+
+- HTTP(S) client ;
+- realtime transport API ;
+- WebSocket baseline ;
+- WebTransport/QUIC candidate ;
+- transport capability negotiation ;
+- fallback transport ;
+- reconnect ;
+- timeout/backoff ;
+- protocole versionné ;
+- session/auth tokens ;
+- validation des messages ;
+- séparation transport/protocole.
+
+La logique de jeu ne dépend pas directement de `tokio-tungstenite`, Quinn, WebTransport ou d'un type de transport concret.
+
+### Logging/telemetry
+
+- tracing ;
+- sinks plateforme ;
+- diagnostics ;
+- métriques séparées du logging.
+
+## Game-systems réutilisables
+
+### Grid/tilemap
+
+- grille ;
+- coordonnées ;
+- layers ;
+- tile occupancy ;
+- topology wrap/toroïdale ;
+- zones/chunks possibles.
+
+### Collision 2D grid
+
+- murs ;
+- obstacles ;
+- entités occupantes ;
+- collision tile/entity.
+
+### Camera/viewport gameplay
+
+- suivi ;
+- scrolling ;
+- bounds ;
+- map plus grande que l'écran.
+
+### Stage/progression
+
+- stage id/version ;
+- start/complete/fail ;
+- transitions ;
+- ordre de stages.
+
+### Lives/attempts
+
+- vie courante ;
+- perte ;
+- continue ;
+- respawn policy.
+
+### Score
+
+- score brut ;
+- bonus ;
+- pénalités ;
+- modifiers ;
+- résultat final explicable.
+
+### Timed entities
+
+- apparition ;
+- durée ;
+- expiration ;
+- respawn ;
+- cooldown.
+
+### Pickup/inventory
+
+- pickups ;
+- capacité ;
+- stacks ;
+- consommables ;
+- activation volontaire.
+
+### Status effects
+
+Réservé pour les évolutions :
+
+- freeze ;
+- poison ;
+- shield ;
+- timed modifiers.
+
+## Uroburas-specific gameplay
+
+### Snake anatomy
+
+- tête ;
+- cou ;
+- corps extensible ;
+- queue ;
+- longueur minimale de quatre unités.
+
+### Snake movement
+
+- direction relative ;
+- interdiction/gestion du demi-tour ;
+- step-based ;
+- auto-forward ;
+- vitesse Snake.
+
+### Snake body geometry
+
+- croissance ;
+- rétrécissement ;
+- propagation de positions ;
+- courbures gauche/droite ;
+- rotation de sprites ;
+- coupure future.
+
+### Uroburas stage rules
+
+- objectifs propres à une map Uroburas ;
+- règles de fin ;
+- règles de croissance/rétrécissement ;
+- interactions propres aux items.
+
+### Uroburas modes
+
+- Challenge ;
+- Persistent Battle Royale ;
+- PvP Battles.
+
+### Combat Uroburas
+
+Future scope :
+
+- feu ;
+- glace ;
+- poison ;
+- protections tête/corps ;
+- téléporteurs ;
+- interaction tête/cou/corps/queue.
+
+Ces concepts restent Uroburas-specific tant qu'un second jeu ne justifie pas leur généralisation.
+
+## Server services
+
+### Identity/account
+
+- PlayerId canonique ;
+- login ;
+- session ;
+- account linking ;
+- external identities ;
+- email verification/recovery.
+
+### Content service
+
+- catalogue maps/skins/assets ;
+- versions ;
+- manifests ;
+- URLs/download authorization ;
+- publication/modération future.
+
+### Asset delivery
+
+- service auto-hébergé ;
+- HTTP/2 baseline ;
+- HTTP/3/QUIC lorsque disponible ;
+- même hostname H2/H3 de préférence ;
+- cache et distribution multi-nœuds futurs ;
+- séparation logique du Content service ;
+- séparation physique uniquement lorsque la charge le justifie.
+
+### Hall of Fame
+
+- score submission ;
+- validation ;
+- classement ;
+- contexte map/ruleset/game version.
+
+### Reward authority
+
+- rewarded ad validation ;
+- continue autorisé ;
+- bonus de stage ;
+- idempotence ;
+- anti-double-credit.
+
+### Realtime session service
+
+Pour Modes 3 puis 2 :
+
+- WebSocket session ;
+- authoritative state ;
+- tick ;
+- snapshots/deltas ;
+- reconnect/resync ;
+- spectator.
+
+### Bot execution
+
+- profils ;
+- décision serveur ;
+- respawn ;
+- simulation de participants.
+
+### Media/replay
+
+Future scope :
+
+- event log ;
+- replay ;
+- rendu/reconstitution ;
+- streaming/enregistrement.
+
+## Providers
+
+- ad provider ;
+- auth provider externe ;
+- email transport provider éventuel ;
+- CDN/object storage ;
+- Play Games/Game Center/Steam futurs.
+
+Le provider n'est jamais l'identité métier canonique.
+
+## Platform adapters
+
+### Desktop SDL
+
+- SDL window/render/input ;
+- keyboard ;
+- filesystem/platform lifecycle.
+
+### Android SDL
+
+- Java/JNI ;
+- touch/virtual controls ;
+- Android lifecycle ;
+- packaging.
+
+### Web/WASM
+
+- browser host ;
+- pointer/touch/keyboard ;
+- storage/browser lifecycle ;
+- asset fetch.
+
+### Tauri
+
+- WebView host ;
+- bridge Rust/Web ;
+- platform plugins.
+
+## Tooling
+
+### Map editor
+
+- création ;
+- validation ;
+- preview/test ;
+- publication.
+
+### Skin editor
+
+- contrat de skin ;
+- preview ;
+- génération contrôlée ;
+- validation.
+
+### Build tooling
+
+- Cargo ;
+- Gradle ;
+- Tauri CLI ;
+- outils natifs de plateforme.
+
+Python n'est pas un outil de build.
+
+### Audit/validation tooling
+
+Python reste autorisé pour :
+
+- audits ;
+- validations complémentaires ;
+- contrôles statiques ;
+- rapports.
+
+## Règle de dépendance
+
+Le jeu dépend vers les couches réutilisables :
+
+```text
+Uroburas game
+    ↓
+game-systems
+    ↓
+technical capabilities
+    ↓
+engine kernel
+```
+
+Les adapters/providers sont composés par les applications/targets, pas appelés directement depuis la logique Uroburas.
+
+Les services serveur partagent des contrats/domain types explicitement dédiés, sans importer les crates client/GUI.

docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md

@@ -0,0 +1,215 @@
+<!-- file: docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md -->
+<!-- version: 2 -->
+
+# Uroburas — étude de décomposition en crates
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.6`.
+
+Les noms ci-dessous sont des candidats, pas encore des crates à créer immédiatement.
+
+## Engine existant
+
+À conserver comme fondation :
+
+```text
+crates/engines/engine-v1-common
+crates/engines/engine-v1-platform-api
+crates/engines/engine-v1-sdl
+```
+
+Le kernel ne doit pas absorber les systèmes de grille, score ou Snake uniquement parce que Uroburas en a besoin.
+
+## Capabilities candidates
+
+Famille possible :
+
+```text
+crates/capabilities/
+    game-assets-lib
+    game-input-lib
+    game-localization-lib
+    game-network-client-lib
+    game-network-realtime-api
+    game-network-websocket-lib
+    game-network-webtransport-lib
+    game-persistence-lib
+    game-audio-lib
+```
+
+Les noms finaux devront respecter les règles workspace et éviter les crates artificiellement petites.
+
+## Game-systems candidates
+
+Famille possible :
+
+```text
+crates/game-systems/
+    game-grid-lib
+    game-collision-grid-lib
+    game-stage-lib
+    game-score-lib
+    game-lives-lib
+    game-timed-entity-lib
+    game-pickup-lib
+```
+
+Ces crates ne sont créées que si leur API est suffisamment stable et réutilisable.
+
+Des mécanismes très liés peuvent rester regroupés dans une même crate plutôt que multiplier les packages.
+
+## Uroburas game crates
+
+Proposition progressive :
+
+```text
+crates/games/
+    game-uroburas-lib
+```
+
+Cette crate compose les règles Uroburas.
+
+Si la complexité le justifie plus tard :
+
+```text
+game-uroburas-core-lib
+game-uroburas-content-lib
+game-uroburas-protocol-lib
+```
+
+Mais ne pas splitter avant besoin réel.
+
+`game-uroburas-lib` ne doit pas dépendre directement de :
+
+- Actix ;
+- Maud ;
+- Lettre ;
+- tokio-tungstenite ;
+- SDK publicitaire ;
+- Java Android ;
+- Tauri API.
+
+## Applications client
+
+Candidats futurs :
+
+```text
+crates/apps/
+    game-uroburas-desktop
+    game-uroburas-wasm
+    game-uroburas-tauri
+    game-uroburas-android-entrypoint
+```
+
+Les apps composent :
+
+- jeu ;
+- adapters plateforme ;
+- capabilities ;
+- providers nécessaires.
+
+## Server crates
+
+Famille proposée :
+
+```text
+crates/servers/
+    uroburas-server-domain-lib
+    uroburas-server-api-lib
+    uroburas-server-web
+    uroburas-server-realtime
+```
+
+Puis seulement si besoin :
+
+```text
+uroburas-server-media
+uroburas-server-admin
+```
+
+### server-domain-lib
+
+Contient des concepts serveur partagés :
+
+- PlayerId ;
+- MapId/MapVersion ;
+- ScoreSubmission ;
+- HallOfFameEntry ;
+- RewardGrant ;
+- Session identifiers.
+
+Ne contient pas Actix/Tungstenite/Tonic.
+
+### server-api-lib
+
+Contrats DTO/protocole :
+
+- HTTP DTOs ;
+- realtime messages indépendants du transport ;
+- WebSocket mapping ;
+- WebTransport mapping futur ;
+- versioning ;
+- validation structurale.
+
+Les wire types restent distincts des modèles métier internes.
+
+### server-web
+
+- Actix Web ;
+- Maud ;
+- auth endpoints ;
+- Hall of Fame ;
+- maps/assets metadata ;
+- administration initiale ;
+- Fluent serveur ;
+- Lettre.
+
+### server-realtime
+
+Future Mode 3/2 :
+
+- Tokio ;
+- tokio-tungstenite comme baseline WebSocket ;
+- WebTransport/QUIC comme transport candidat ;
+- adaptation transport séparée de la simulation ;
+- rooms/worlds ;
+- authoritative simulation ;
+- snapshots/deltas ;
+- spectator ;
+- bots.
+
+## Providers
+
+Famille possible :
+
+```text
+crates/providers/
+    game-ads-api-lib
+    game-ads-<provider>-lib
+    game-auth-<provider>-lib
+```
+
+Ne pas créer les providers tant qu'ils ne sont pas nécessaires à une cible réelle.
+
+## Tooling
+
+Candidats futurs :
+
+```text
+crates/tools/
+    uroburas-map-editor
+    uroburas-skin-editor
+```
+
+Un éditeur Web peut aussi avoir sa propre app/host au lieu d'être une crate de jeu.
+
+## Anti-monolithe
+
+Avant d'ajouter une fonctionnalité à `game-uroburas-lib`, poser trois questions :
+
+1. connaît-elle explicitement les règles Uroburas ?
+2. serait-elle utile dans un autre jeu sans référence à Uroburas ?
+3. dépend-elle d'une plateforme, d'un transport ou d'un provider ?
+
+Si la réponse à 1 est non et à 2 ou 3 est oui, elle appartient probablement ailleurs.

docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md

@@ -0,0 +1,255 @@
+<!-- file: docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md -->
+<!-- version: 2 -->
+
+# Uroburas — stack serveur de référence
+
+## Statut
+
+Étude de référence pour `0.2.0-0-pre.6`.
+
+## Runtime async
+
+Référence :
+
+```text
+Tokio
+```
+
+## HTTP / Web
+
+Référence :
+
+```text
+Actix Web
+```
+
+Responsabilités initiales :
+
+- auth ;
+- compte ;
+- maps/assets metadata ;
+- Hall of Fame ;
+- rewarded grants ;
+- admin initiale ;
+- pages Web.
+
+## HTML server-side
+
+Référence :
+
+```text
+Maud
+```
+
+Objectif :
+
+- rendu HTML côté Rust ;
+- pages compte ;
+- Hall of Fame ;
+- administration ;
+- pages jeu/portail.
+
+Le JavaScript reste réservé aux interactions qui le nécessitent.
+
+## Asset delivery auto-hébergé
+
+La distribution des maps, skins, sons, sprites, bundles Fluent et autres assets reste auto-hébergée par défaut.
+
+Direction :
+
+```text
+assets.games.sasedev.com
+    HTTP/2
+    HTTP/3/QUIC lorsque disponible
+```
+
+Le même hostname doit de préférence accepter H2 et H3 avec fallback transparent.
+
+La topologie initiale peut rester sur une seule machine, avec séparation logique des hostnames/services. La séparation physique vient ensuite :
+
+```text
+Web/API
+Asset delivery
+Realtime
+Database
+Media/replay
+```
+
+puis plusieurs nœuds/cache d'assets si la charge le justifie.
+
+Aucun CDN tiers n'est une dépendance architecturale obligatoire.
+
+## Realtime public
+
+Baseline :
+
+```text
+Tokio + tokio-tungstenite
+```
+
+Candidat à benchmarker :
+
+```text
+WebTransport / QUIC
+```
+
+Utilisé pour les futurs Modes 3 puis 2.
+
+La capability client doit exposer les propriétés du transport plutôt que simuler une équivalence artificielle :
+
+```text
+reliable ordered
+streams
+datagrams
+connection migration
+```
+
+WebSocket reste le fallback universel lorsque WebTransport n'est pas disponible ou échoue.
+
+La logique de gameplay ne dépend pas directement des types Tungstenite, WebTransport ou QUIC.
+
+Le transport reste encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
+
+## gRPC
+
+Référence conditionnelle :
+
+```text
+tonic
+```
+
+Utilisation envisagée :
+
+- server-to-server ;
+- worker média/replay ;
+- orchestration interne ;
+- appels typés entre services lorsque la séparation physique le justifie.
+
+gRPC n'est pas obligatoire pour le transport public client/gameplay.
+
+Le client public utilise en priorité :
+
+```text
+HTTPS
++
+WebSocket baseline
++
+WebTransport lorsque disponible et validé
+```
+
+gRPC n'est pas utilisé comme remplacement obligatoire du transport gameplay public.
+
+## Localization
+
+Référence :
+
+```text
+Fluent / fluent-bundle
+```
+
+Côté client :
+
+- menus ;
+- HUD ;
+- erreurs ;
+- contenu localisé ;
+- maps/assets téléchargeables.
+
+Côté serveur :
+
+- HTML ;
+- emails ;
+- messages utilisateur ;
+- administration.
+
+Les protocoles transportent des codes/identifiants métier, pas des chaînes déjà traduites.
+
+## Email
+
+Référence :
+
+```text
+Lettre
+```
+
+Cas initiaux possibles :
+
+- vérification de compte ;
+- reset password ;
+- notifications sécurité ;
+- magic link si retenu.
+
+Les contenus email utilisent Fluent.
+
+## Séparation des modèles
+
+Ne pas partager directement comme modèles métier :
+
+- types Actix ;
+- types Tungstenite ;
+- messages protobuf ;
+- types Maud.
+
+Séparation attendue :
+
+```text
+domain model
+HTTP DTO
+WebSocket protocol
+gRPC contracts
+HTML view model
+```
+
+## Performance
+
+La stack realtime doit être validée par benchmarks de charge avant gel long terme.
+
+Mesures candidates :
+
+- connexions concurrentes ;
+- mémoire/connexion ;
+- messages/s ;
+- bytes/s ;
+- p50/p95/p99 ;
+- backpressure ;
+- coût broadcast ;
+- coût interest management ;
+- reconnect/resync ;
+- CPU par tick.
+
+Le choix `tokio-tungstenite` est la référence initiale, pas une affirmation non mesurée de supériorité universelle.
+
+## Frontière transport / protocole
+
+La stack doit distinguer :
+
+```text
+transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+synchronization
+    ↓
+authoritative simulation
+```
+
+Cette séparation permet de comparer WebSocket et WebTransport sur le même protocole métier.
+
+## POC réseau futur
+
+Avant gel long terme du transport realtime, la série POC doit comparer au minimum :
+
+- WebSocket / tokio-tungstenite ;
+- WebTransport / QUIC ;
+- fallback automatique ;
+- pics de connexions ;
+- mémoire/connexion ;
+- CPU ;
+- p50/p95/p99 ;
+- pertes réseau ;
+- backpressure ;
+- mobilité réseau ;
+- snapshots/deltas ;
+- broadcast/interest management.

docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md

@@ -0,0 +1,118 @@
+<!-- file: docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md -->
+<!-- version: 2 -->
+
+# Uroburas — ordre d'implémentation par dépendances
+
+## Statut
+
+Étude non normative pour `0.2.0-0-pre.6`.
+
+## Principe
+
+Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les frontières permettant d'ajouter Mode 3 puis Mode 2.
+
+## Phase A — fondations réutilisables
+
+À stabiliser avant le jeu final :
+
+- input semantic actions ;
+- boutons virtuels tactiles ;
+- render sprite/rotation/caméra ;
+- grid/tilemap toroïdale ;
+- collision obstacles ;
+- assets/content manifest ;
+- téléchargement/cache ;
+- localization Fluent ;
+- persistence settings/cache.
+
+## Phase B — systèmes nécessaires au Challenge
+
+- stages ;
+- vies ;
+- score ;
+- timers ;
+- pickups/items simples ;
+- spawn/respawn ;
+- caméra map large ;
+- transitions de stages.
+
+## Phase C — Uroburas Challenge
+
+- anatomie Snake ;
+- mouvement ;
+- corps extensible ;
+- longueur minimale ;
+- sprites/virages ;
+- règles de maps ;
+- progression de run ;
+- Hall of Fame local submission model.
+
+## Phase D — services Web V1
+
+- Actix Web ;
+- Maud ;
+- auth ;
+- PlayerId ;
+- Fluent serveur ;
+- Lettre ;
+- maps/assets metadata ;
+- asset delivery auto-hébergé ;
+- HTTP/2 baseline et HTTP/3 si disponible côté asset delivery ;
+- Hall of Fame ;
+- rewarded ad authority ;
+- protocole HTTP sécurisé/versionné.
+
+## Phase E — intégration client/server Mode 1
+
+- login/session ;
+- téléchargement contenu ;
+- score submission ;
+- rewarded continue ;
+- rewarded score multiplier ;
+- validation/retry/idempotence ;
+- offline degradation.
+
+## Phase F — Mode 3
+
+Une fois les moteurs Mode 1 stables :
+
+- server realtime ;
+- realtime transport API ;
+- tokio-tungstenite baseline ;
+- WebTransport/QUIC candidat après POC ;
+- fallback transport ;
+- authoritative simulation ;
+- world persistence lifecycle ;
+- bots ;
+- spectator ;
+- snapshots/deltas ;
+- interest management ;
+- rejoin cooldown ;
+- future combat/items.
+
+## Phase G — Mode 2
+
+Après réutilisation des briques realtime du Mode 3 :
+
+- lobby/matchmaking ;
+- private matches ;
+- map selection ;
+- teams ;
+- bounded matches ;
+- lives/match rules ;
+- spectator policy ;
+- bots optionnels.
+
+## Tooling en parallèle
+
+L'éditeur de maps peut commencer lorsqu'un format de map suffisamment stable existe.
+
+L'éditeur de skins vient après stabilisation du contrat de skin.
+
+Ni l'un ni l'autre ne doit bloquer le premier gameplay Challenge minimal.
+
+## POC transport avant Mode 3
+
+Avant de figer le transport realtime du Mode 3, un POC dédié doit comparer WebSocket et WebTransport avec la même couche protocolaire.
+
+Le POC mesure la charge et la robustesse ; il ne doit pas forcer la simulation Uroburas à dépendre d'une implémentation réseau particulière.

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

@@ -0,0 +1,29 @@
+<!-- file: history/0.2.0/0-pre.1.fix.2.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.1.fix.2
+
+## Statut
+
+Jalon de gouvernance documentaire accepté avant ouverture de `0.2.0-0-pre.2`.
+
+## Décisions validées
+
+- séparation `ideas / studies / architecture / rules` ;
+- points d'entrée documentaires `000-README.md` ;
+- marqueurs `( )`, `(x)`, `(d)`, `(c)` pour les listes de tâches durables ;
+- ROADMAP conservant reports et annulations ;
+- CHANGELOG synthétique à partir des RC et releases stables ;
+- deltas immuables sur le fond ;
+- manifests `*.delete.txt` documentés ;
+- incrément obligatoire des versions d'en-tête lors de modifications réelles ;
+- matrice évolutive de commandes/validations ;
+- politique de nettoyage Cargo périodique ;
+- règles de modification en RC ;
+- génération du prompt suivant après première RC réellement gelée ;
+- réservation macOS/iOS sans engagement d'implémentation ;
+- Cargo comme version produit canonique des applications Tauri lorsque l'outil le permet.
+
+## Suite
+
+`0.2.0-0-pre.2` ouvre l'étude fonctionnelle et le découpage par kernel, capabilities, game-systems, plateformes, providers, services et logique propre aux jeux.

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.

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

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

@@ -0,0 +1,18 @@
+<!-- file: history/0.2.0/0-pre.4.fix.2.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.4.fix.2
+
+## Statut
+
+Étude des POC plateforme validée avant ouverture de `0.2.0-0-pre.5`.
+
+## Contenu accepté
+
+- Snake comme jeu-sonde unique des futurs POC plateforme ;
+- comparaison SDL natif / Web-WASM / Tauri-WebView ;
+- Tauri Android + Snake ;
+- Web direct + Snake ;
+- Tauri Desktop + Snake ;
+- builder Android multi-ABI comme POC tooling ;
+- matrice commune de validation des POC.

history/0.2.0/0-pre.5.fix.1.md

@@ -0,0 +1,19 @@
+<!-- file: history/0.2.0/0-pre.5.fix.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.5.fix.1
+
+## Statut
+
+Spécification fonctionnelle Uroburas acceptée comme base de classification avant `0-pre.6`.
+
+## Points structurants
+
+- première version centrée Mode 1 Challenge ;
+- ordre prévu Mode 1 → Mode 3 → Mode 2 ;
+- anatomie minimale tête + cou + corps + queue ;
+- corps seul extensible ;
+- maps/assets/skins téléchargeables ;
+- virtual directional buttons Mobile/Tablet ;
+- Hall of Fame, auth et rewarded ads dès la première trajectoire ;
+- combat avancé conservé pour les évolutions ultérieures.

history/0.2.0/0-pre.7.md

@@ -0,0 +1,30 @@
+<!-- file: history/0.2.0/0-pre.7.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.7
+
+## Statut
+
+Consolidation architecturale validée avant ouverture de `0.2.0-0-pre.8`.
+
+## Validation utilisateur
+
+Les audits suivants ont été exécutés et validés :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (4 table(s), 156 file(s))
+Distribution layout audit: clean
+```
+
+## Contenu validé
+
+- architecture modulaire et ownership ;
+- architecture réseau/serveur ;
+- architecture cible Uroburas ;
+- architecture POC plateforme/réseau ;
+- règles de cadrage des sessions/prompts ;
+- préférence d'auto-hébergement Debian Stable ;
+- absence de gel prématuré d'un edge/reverse proxy HTTP/3.

history/0.2.0/0-pre.8.fix.1.md

@@ -0,0 +1,28 @@
+<!-- file: history/0.2.0/0-pre.8.fix.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-0-pre.8.fix.1
+
+## Statut
+
+Dernière prerelease documentaire validée avant `0.2.0-3-rc.1`.
+
+## Validation utilisateur
+
+Les audits suivants ont été exécutés et validés :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (4 table(s), 161 file(s))
+Distribution layout audit: clean
+```
+
+## Contenu validé
+
+- baseline architecturale consolidée `0.2.0` ;
+- ROADMAP `0.2.0` fermé ;
+- résumé CHANGELOG préparé ;
+- prompt `0.3.x` renforcé avec forecast souple inspiré du workflow KSP ;
+- sizing `pre.1`, trajectoire `0.3.0` et projection initiale de la série `0.3.x`.

history/0.2.0/3-rc.1.md

@@ -0,0 +1,26 @@
+<!-- file: history/0.2.0/3-rc.1.md -->
+<!-- version: 1 -->
+
+# Historique 0.2.0-3-rc.1
+
+## Statut
+
+Candidate de publication validée avant promotion mécanique vers `0.2.0`.
+
+## Validation utilisateur
+
+Les audits suivants ont été exécutés et validés :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (4 table(s), 164 file(s))
+Distribution layout audit: clean
+```
+
+## Décision
+
+Aucune correction sémantique n'est requise.
+
+La release `0.2.0` peut être produite mécaniquement à partir de cette candidate.

history/000-README.md

@@ -1,4 +1,4 @@
-<!-- file: history/README.md -->
+<!-- file: history/000-README.md -->
 <!-- version: 1 -->
 
 # Historique transitoire validé

prompts/001-V0_2_0_START_PROMPT.md

@@ -1,84 +1,76 @@
 <!-- file: prompts/001-V0_2_0_START_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
-# Prompt de démarrage 0.2.0 — conception du framework modulaire
+# Prompt de démarrage 0.2.0 — conception progressive 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.
+Partir de la version stable `0.1.0` et considérer cette version comme la clôture du POC multi-plateforme.
 
-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.
+Lire intégralement `RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/000-README.md`, `docs/architecture/011-POST_0_1_0_DIRECTION.md`, `history/0.1.0/3-rc.1.fix.1.md` et `deltas/0.1.0/rel.md` avant toute proposition.
 
-## Objectif
+## Principe de la version
 
-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.
+`0.2.0` est une version de conception et de réservation architecturale.
 
-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.
+Elle ne doit pas être produite en une seule livraison supposée finale. Utiliser plusieurs `0-pre.N` documentaires afin que le contenu soit relu, discuté, corrigé et complété avant RC.
 
-## Travail de conception obligatoire
+Les audits Markdown ou de règles valident la forme mais ne valent jamais validation humaine du fond.
 
-Effectuer les étapes suivantes dans cet ordre, avec discussion/audit avant gel :
+## Ordre de travail
 
-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.
+### `0-pre.1` — gouvernance documentaire
 
-## Exemples de pression architecturale
+Fixer avant le catalogue fonctionnel :
 
-Utiliser des jeux concrets pour tester la conception, sans les implémenter tous immédiatement.
+- catégories `ideas`, `studies`, `architecture`, `rules` et leurs responsabilités ;
+- nomenclature documentaire et points d'entrée `000-README.md` des répertoires documentaires multi-fichiers ;
+- statuts de suivi `( )`, `(x)`, `(d)`, `(c)` pour ROADMAP et autres listes de tâches durables ;
+- comportement d'un scope partiellement réalisé, reporté ou annulé ;
+- rôle du CHANGELOG limité aux jalons RC et stables ;
+- règles de modification autorisée/interdite en RC et moment de génération du prompt suivant ;
+- matrice numérotée des commandes/validations, dépendances entre gates et politique de nettoyage Cargo ;
+- rôles respectifs de `deltas/` et `history/` ;
+- maturation `Idea → Study → Architectural decision → Reserved capability → Planned → Implemented` ;
+- validation humaine obligatoire des prereleases documentaires.
 
-### Snake
+Ne pas encore figer le catalogue complet des capabilities dans cette étape.
 
-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.
+### `0-pre.2` et suivantes — conception fonctionnelle progressive
 
-### Reflex
+Après validation humaine de la gouvernance documentaire :
 
-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.
+1. inventorier les capabilities déjà justifiées par les jeux et plateformes envisagés ;
+2. distinguer capability générique, système de jeu réutilisable et logique propre à un jeu ;
+3. définir les couches et dépendances autorisées ;
+4. établir la matrice plateformes en réservant notamment Linux, Windows, macOS, Android, iOS et Web sans confondre OS, classe de device et backend ;
+5. formaliser les archétypes de jeux servant de pression architecturale ;
+6. définir la composition statique et le manifest produit/jeu ;
+7. définir l'architecture cible des crates sans les créer prématurément ;
+8. traiter progressivement logging, auth/identity, online/offline, persistence/sync, ads/providers, leaderboards, multiplayer, assets/CDN et services Web ;
+9. étudier Tauri Android par un futur POC comparatif sans décider à l'avance qu'il remplace SDL Android ;
+10. préparer le remplacement de l'orchestration Android Python du POC par un outil multi-ABI adapté au projet.
 
 ## 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.
+- ne pas créer une crate pour chaque idée ;
+- ne pas considérer une idée comme une capability réservée ;
+- ne pas figer une API purement spéculative ;
+- conserver le gameplay indépendant des APIs de providers et plateformes ;
+- préférer la composition statique Rust par produit ;
+- ne pas faire des Cargo features globales le système principal de composition ;
+- permettre qu'un jeu ne cible qu'une partie des plateformes ;
+- permettre `offline-only`, `online-optional` et `online-required` selon le jeu ;
+- conserver les décisions rejetées ou reportées dans les documents adaptés plutôt que réécrire l'histoire.
 
-## Résultat attendu de la première session 0.2.0
+## Validation
 
-La session doit d'abord produire une architecture documentée cohérente et une roadmap d'implémentation progressive.
+Chaque prerelease documentaire est livrée comme delta relisible.
 
-Le développement fonctionnel significatif ne commence qu'après validation de cette conception.
+Le passage au delta suivant nécessite :
+
+1. audits syntaxiques propres ;
+2. revue humaine explicite du contenu ;
+3. corrections ou compléments demandés ;
+4. enregistrement du jalon validé dans `history/` seulement dans le delta suivant.
+
+Ne pas promouvoir `0.2.0` en RC ou stable sur la seule base des audits automatisés.

prompts/002-V0_3_X_START_PROMPT.md

@@ -0,0 +1,440 @@
+<!-- file: prompts/002-V0_3_X_START_PROMPT.md -->
+<!-- version: 2 -->
+
+# Prompt de démarrage — `0.3.0` / série `0.3.x` POC plateforme et réseau
+
+## Base
+
+Partir du tag stable `v0.2.0`.
+
+Avant toute modification :
+
+1. lire `RULES.md`, `ROADMAP.md`, `CHANGELOG.md` et `docs/000-README.md` ;
+2. lire les règles de session, commandes et validation ;
+3. lire les architectures consolidées `012` à `016` ;
+4. vérifier l'état Git/workspace ;
+5. exécuter les audits applicables à la base ;
+6. confirmer la version workspace avant `0.3.0-0-pre.1`.
+
+Documents prioritaires :
+
+- `docs/rules/RULES_SESSION_PLANNING.md` ;
+- `docs/rules/RULES_COMMANDS.md` ;
+- `docs/rules/RULES_VALIDATION_MATRIX.md` ;
+- `docs/rules/RULES_SERVER_HOSTING.md` ;
+- `docs/architecture/012-MODULAR_LAYERING_AND_OWNERSHIP.md` ;
+- `docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md` ;
+- `docs/architecture/014-UROBURAS_TARGET_ARCHITECTURE.md` ;
+- `docs/architecture/015-PLATFORM_POC_ARCHITECTURE.md` ;
+- `docs/architecture/016-V0_2_0_CONSOLIDATED_BASELINE.md`.
+
+## Mission de `0.3.0`
+
+`0.3.0` ouvre la série de POC.
+
+Son objectif n'est pas de commencer Uroburas, mais de rendre la base Snake suffisamment propre pour servir de sonde multiplateforme et de réaliser un premier POC de bout en bout sans duplication incontrôlée.
+
+Résultat attendu :
+
+- baseline Snake réutilisable ;
+- inventaire des adapters/capabilities réellement nécessaires ;
+- premier chemin POC exécuté de bout en bout ;
+- procédures de build natives documentées ;
+- validations reproductibles ;
+- décision explicite sur ce qui est extrait, conservé localement ou reporté ;
+- version suivante planifiée à partir des résultats réels.
+
+## Contraintes gelées
+
+Préserver :
+
+```text
+game-specific
+    ↓
+game-systems
+    ↓
+technical capabilities
+    ↓
+engine kernel
+```
+
+Les adapters/providers sont composés au niveau app/product.
+
+Snake est le jeu-sonde principal de `0.3.x`.
+
+Uroburas reste réservé à `0.4.x`.
+
+Les builds utilisent Cargo, Gradle, Tauri CLI ou la toolchain native appropriée.
+
+Python reste autorisé pour audits et validations complémentaires, jamais comme orchestrateur de build.
+
+L'utilisateur exécute les builds, tests unitaires/intégration et smoke tests demandés.
+
+## `0.3.0-0-pre.1` — cadrage obligatoire
+
+Cette tranche précède toute implémentation lourde.
+
+Elle doit couvrir :
+
+### Audit de la base
+
+- crates Snake existantes ;
+- Desktop SDL ;
+- Android SDL/Java/JNI ;
+- Tauri/WASM Reflex existant comme référence technique ;
+- abstractions déjà réutilisables ;
+- duplications ;
+- scripts/outils ;
+- procédures de build réellement disponibles ;
+- contraintes de l'environnement courant.
+
+### Requirements POC
+
+Identifier les besoins réels pour Snake :
+
+- input clavier ;
+- virtual directional buttons tactiles ;
+- viewport/resize ;
+- lifecycle ;
+- runtime provenance ;
+- assets ;
+- logging ;
+- WASM bridge ;
+- Tauri bridge ;
+- Android packaging ;
+- multi-ABI.
+
+### Sizing
+
+Le forecast ci-dessous est une hypothèse.
+
+`pre.1` doit explicitement :
+
+- le confirmer ou le corriger ;
+- fusionner les tranches trop petites ;
+- scinder les tranches trop lourdes ;
+- reporter ce qui ne tient pas dans `0.3.0` ;
+- vérifier que `0.3.0` peut être terminé dans une seule session.
+
+Si ce n'est pas réaliste, réduire immédiatement le scope de `0.3.0`.
+
+## Forecast souple de `0.3.0`
+
+### `0-pre.1` — audit / brainstorming / requirements / sizing
+
+Objectif :
+
+- audit de la baseline ;
+- requirements ;
+- graphe de dépendances ;
+- choix du premier POC ;
+- forecast corrigé ;
+- commandes prévues ;
+- critères de sortie.
+
+Pas de gros développement avant fermeture de ce cadrage.
+
+### `0-pre.2` — Snake portability baseline
+
+Objectif candidat :
+
+- corriger les dépendances trop spécifiques à un launcher ;
+- stabiliser les semantic actions ;
+- vérifier gameplay vs platform input ;
+- préparer plusieurs hosts ;
+- ne pas ajouter de logique Uroburas.
+
+Validation candidate :
+
+- tests ciblés Snake ;
+- Desktop SDL toujours fonctionnel ;
+- dependency audit ciblé.
+
+### `0-pre.3` — adapters/capabilities minimaux
+
+Objectif candidat :
+
+- extraire uniquement ce que le premier POC prouve nécessaire ;
+- éviter duplication bridge/frontend ;
+- préparer input/resize/lifecycle/runtime provenance ;
+- documenter les duplications provisoires.
+
+Cette tranche peut être fusionnée avec `pre.2`.
+
+### `0-pre.4` — premier POC de bout en bout
+
+Préférence initiale :
+
+```text
+Tauri Android + Snake
+```
+
+Alternative si `pre.1` la juge plus rationnelle :
+
+```text
+Web navigateur direct + Snake
+```
+
+Le POC doit couvrir :
+
+- build avec outil natif ;
+- lancement ;
+- rendu ;
+- contrôles ;
+- resize/orientation selon host ;
+- lifecycle ;
+- logging ;
+- assets ;
+- runtime provenance.
+
+Compiler seul ne suffit pas.
+
+### `0-pre.5` — corrections/généralisation issues du POC
+
+Créer seulement si le POC révèle un besoin réel :
+
+- supprimer duplication avérée ;
+- corriger frontières mal placées ;
+- ajouter tests nécessaires ;
+- documenter ce qui reste spécifique.
+
+### `1-alpha.1` — intégration éventuelle
+
+À utiliser seulement si le volume de code nouveau justifie une phase distincte.
+
+Objectif :
+
+- stabiliser interfaces Snake/capabilities/host ;
+- fermer les défauts structurels ;
+- aucun nouveau scope.
+
+Sinon, ne pas créer cette tranche artificiellement.
+
+### `2-beta.1` — validation large
+
+Objectif :
+
+- feature-complete pour le scope réel de `0.3.0` ;
+- builds/tests applicables ;
+- smoke du POC ;
+- documentation des commandes ;
+- vérification qu'aucune abstraction spéculative n'a été ajoutée.
+
+### `3-rc.1` — candidate
+
+Scope gelé.
+
+Autorisé :
+
+- bugfix ;
+- tests ;
+- documentation ;
+- packaging ;
+- compatibilité.
+
+Interdit :
+
+- nouveau POC ;
+- nouvelle capability non nécessaire ;
+- changement d'objectif.
+
+### `0.3.0`
+
+Release mécanique après validation RC.
+
+## Forecast initial de la série `0.3.x`
+
+Ce forecast est indicatif et doit évoluer avec les résultats.
+
+### `0.3.0` — baseline POC + premier host
+
+- nettoyer la sonde Snake ;
+- éprouver une première composition multiplateforme ;
+- premier POC de bout en bout.
+
+### `0.3.1` — second host Snake
+
+Candidat :
+
+- Web direct si Tauri Android a été fait en `0.3.0` ;
+- Tauri Android si Web direct a été fait en `0.3.0`.
+
+But : vérifier que les abstractions du premier POC ne sont pas sur-spécialisées.
+
+### `0.3.2` — Tauri Desktop + Snake / factorisation WebView
+
+- éprouver la réutilisation bridge/frontend ;
+- factoriser uniquement ce que les POC justifient.
+
+### `0.3.3` — Android multi-ABI natif
+
+- Cargo/Gradle réels ;
+- ARM64 ;
+- x86_64 ;
+- Debug/Release selon scope ;
+- procédures reproductibles ;
+- aucun script Python de build.
+
+### `0.3.4` — realtime transport API + WebSocket baseline
+
+- API de transport indépendante ;
+- `tokio-tungstenite` baseline ;
+- codec/protocol/session séparés ;
+- harness de test ;
+- aucun serveur Uroburas Mode 3.
+
+### `0.3.5` — WebTransport/QUIC POC
+
+- implémentation candidate ;
+- fallback WebSocket ;
+- même protocole ;
+- comparaison charge/latence/mémoire/backpressure/reconnect ;
+- décision conserver/report/rejeter.
+
+### `0.3.6` — consolidation POC
+
+- réconcilier résultats plateforme/réseau ;
+- promouvoir décisions validées ;
+- retirer les abstractions non justifiées ;
+- préparer la baseline `0.4.x`.
+
+La numérotation `0.3.1+` n'est pas contractuelle.
+
+Une version peut être fusionnée, scindée, reportée ou supprimée.
+
+## Dépendances entre versions
+
+Ne pas commencer un POC parce qu'il figure dans le forecast.
+
+Avant ouverture :
+
+- version précédente validée ;
+- abstractions produites comprises ;
+- nouvelle question technique encore ouverte ;
+- environnement réel disponible.
+
+Windows/macOS/iOS SDL ne sont ouverts qu'avec un environnement permettant une validation réelle.
+
+## POC réseau
+
+Architecture à préserver :
+
+```text
+realtime transport
+    ↓
+wire codec
+    ↓
+session protocol
+    ↓
+sync/reconnect
+    ↓
+consumer
+```
+
+Candidats :
+
+```text
+WebSocket
+    tokio-tungstenite
+
+WebTransport
+    QUIC
+```
+
+WebSocket reste baseline/fallback.
+
+WebTransport n'est conservé que si les mesures justifient sa complexité.
+
+Mesures candidates :
+
+- connexions concurrentes ;
+- mémoire/connexion ;
+- CPU ;
+- messages/s ;
+- bytes/s ;
+- p50/p95/p99 ;
+- backpressure ;
+- perte réseau ;
+- reconnect ;
+- changement réseau ;
+- snapshots/deltas.
+
+## Web / serveur / auto-hébergement
+
+Références :
+
+```text
+Tokio
+Actix Web
+Maud
+Fluent / fluent-bundle
+Lettre
+```
+
+Tonic/gRPC reste conditionnel aux besoins server-to-server.
+
+Asset delivery :
+
+```text
+self-hosted
+HTTP/2 baseline
+HTTP/3/QUIC candidat
+```
+
+Debian Stable reste la cible opérationnelle préférée.
+
+Ne pas figer HAProxy, nginx ou autre edge sans POC et vérification de maturité/disponibilité sur Debian Stable.
+
+## Validation
+
+Appliquer les gates proportionnelles au scope.
+
+Toujours distinguer :
+
+- validations exécutées ;
+- validations à exécuter par l'utilisateur ;
+- validations impossibles dans l'environnement courant.
+
+Les commandes doivent être copiables depuis le delta.
+
+Préférer les validations ciblées pendant les tranches ; réserver les gates larges aux frontières beta/RC.
+
+## Livraison
+
+Chaque tranche produit :
+
+```text
+games-sasedev-<semver>-delta.zip
+```
+
+Les deltas sont immuables.
+
+Une correction s'effectue via `.fix.N`.
+
+Les changements réels incrémentent les en-têtes `version`.
+
+## Discipline de session
+
+Le forecast sert à estimer et ordonner, pas à imposer des prereleases inutiles.
+
+Une version doit être terminée dans une seule session.
+
+Si un objectif devient trop gros :
+
+- fermer proprement le scope courant ;
+- reporter explicitement le reste ;
+- ouvrir une version suivante.
+
+## Condition de fin de `0.3.0`
+
+`0.3.0` est terminée lorsque :
+
+- le scope corrigé en `pre.1` est intégralement livré ;
+- le premier POC choisi fonctionne réellement sur son host ;
+- les builds utilisent les outils natifs ;
+- Snake reste séparé des adapters ;
+- les abstractions extraites sont justifiées ;
+- tests/gates applicables validés ;
+- documentation durable à jour ;
+- ROADMAP/CHANGELOG mis à jour selon le stade ;
+- version suivante préparée à partir des résultats réels.

scripts/audit_project_workspace_rules.py

@@ -1,6 +1,6 @@
 #!/usr/bin/env python3
 # file: scripts/audit_project_workspace_rules.py
-# version: 4
+# version: 5
 
 """Audit mechanically verifiable games.sasedev workspace boundaries."""
 
@@ -67,7 +67,7 @@ def main() -> int:
     if history_root.exists():
         for history_path in sorted(history_root.rglob("*.md")):
             relative_history = history_path.relative_to(history_root)
-            if relative_history.as_posix() == "README.md":
+            if relative_history.as_posix() == "000-README.md":
                 continue
             if len(relative_history.parts) != 2:
                 errors.append(f"DOC-010: history file must use history/<X.Y.Z>/<label>.md: {history_path.relative_to(root).as_posix()}")
@@ -79,6 +79,13 @@ def main() -> int:
             candidate = f"{base_version}-{label}"
             if SEMVER.fullmatch(candidate) is None:
                 errors.append(f"DOC-010: invalid history milestone filename: {history_path.relative_to(root).as_posix()}")
+
+    docs_root = root / "docs"
+    if docs_root.exists():
+        for readme_path in sorted(docs_root.rglob("README.md")):
+            errors.append(
+                f"DOC-011: documentary directory entry point must use 000-README.md: {readme_path.relative_to(root).as_posix()}"
+            )
     forbidden_assets = [path for path in (root / "crates").rglob("assets") if path.is_dir()]
     for path in forbidden_assets:
         errors.append(f"GAME-ASSET-001: assets directory forbidden inside crates: {path.relative_to(root).as_posix()}")