0.2.0-0-pre.1

Android/game-reflex-poc/build.gradle

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

Android/game-snake-poc/build.gradle

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

CHANGELOG.md

@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Changelog
 
@@ -9,8 +9,7 @@
 - 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 ;
+- réservation de la direction `0.2.0` pour concevoir progressivement le framework modulaire avant toute extension fonctionnelle majeure.
-- ajout d'un prompt de conception `0.2.0` afin que l'inventaire détaillé des fonctionnalités et la future architecture soient discutés avant toute implémentation majeure.
 
 ## 0.1.0-3-rc.1 — 2026-09-17
 
@@ -20,59 +19,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
+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/`.
-
-- 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.

Cargo.toml

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

README.md

@@ -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-0-pre.1`.
 
 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,32 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # 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.1.0` — squelette du workspace, règles, architecture, versions et assets.
-- [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.1.0` — moteur V1 POC, boucle de jeu, input abstrait et rendu SDL3 minimal.
-- [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.1.0` — Reflex et Snake jouables comme POC de réutilisation.
-- [x] `0-pre.4` — architecture de tests hors `src/`, stratégie de tests ciblés et socle `tracing`/`tracing-subscriber`/`tracing-appender`.
+- (x) `0.1.0` — Desktop SDL3 natif, Android SDL3/Java/JNI et Tauri/WebView/WASM Reflex.
-- [x] `0-pre.5` — intégration SDL3 Desktop réelle et premier rendu POC Reflex.
+- (x) `0.1.0` — tracing commun, provenance runtime, packaging et validation multi-appareils.
-- [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.
+Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `history/0.1.0/`.
-- [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.
 
 ## 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.
+- ( ) `0.2.0` — fixer la gouvernance documentaire, la nomenclature et le cycle de maturation des idées et décisions.
+- ( ) `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.

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

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

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

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

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/README.md` ;
+- `docs/studies/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.

docs/000-README.md

@@ -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/README.md`](ideas/README.md) — rôle des idées non engagées et règles de maturation.
+- [`studies/README.md`](studies/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.
@@ -40,7 +45,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 et [`rules/RULES_COMMANDS.md`](rules/RULES_COMMANDS.md) pour la politique d'exécution des commandes.
 
 ## Validation
 

docs/ideas/README.md

@@ -0,0 +1,22 @@
+<!-- file: docs/ideas/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

@@ -5,11 +5,13 @@
 
 - `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.
+- `ROADMAP.md` conserve le planning durable et son historique de scope via `( )`, `(x)`, `(d)` et `(c)`.
-- `CHANGELOG.md` conserve l'historique synthétique inversement chronologique.
+- `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/` contient des idées et variantes non engagées.
+- `docs/studies/` contient 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.

docs/rules/RULES_DOCUMENTATION.md

@@ -1,8 +1,10 @@
 <!-- file: docs/rules/RULES_DOCUMENTATION.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # 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/`.
@@ -11,11 +13,72 @@
 - **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-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é.
+## Catégories documentaires
-- **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-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-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-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-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-CAT-003** — `docs/architecture/` contient uniquement des orientations ou décisions architecturales retenues. Une possibilité encore ouverte reste dans `ideas/` ou `studies/`.
-- **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-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-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.
+- **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.
+
+## 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** — Les marqueurs ROADMAP canoniques sont exclusivement `( )`, `(x)`, `(d)` et `(c)`. La syntaxe Markdown task-list `[ ]` / `[x]` n'est pas utilisée.
+- **DOC-RMAP-003** — `( )` signifie `planned`, `(x)` signifie `completed`, `(d)` signifie `deferred` et `(c)` signifie `cancelled`.
+- **DOC-RMAP-004** — Les marqueurs sont des statuts de lignes de scope, pas nécessairement un statut global de version.
+- **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.

docs/rules/VERSION_WORKFLOW.md

@@ -73,3 +73,18 @@ 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é.

docs/studies/README.md

@@ -0,0 +1,17 @@
+<!-- file: docs/studies/README.md -->
+<!-- version: 1 -->
+
+# É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.

prompts/001-V0_2_0_START_PROMPT.md

@@ -1,84 +1,74 @@
 <!-- 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 ;
+### `0-pre.1` — gouvernance documentaire
-2. classer chaque élément dans une couche explicite : `kernel`, `capability`, `platform adapter`, `provider`, `game/system`, `server/service` ou `tooling` ;
-3. définir les dépendances autorisées et interdites entre ces couches ;
-4. définir une matrice des capacités par plateforme : Desktop SDL, Android SDL, Web/WASM, Tauri Desktop et Tauri Android expérimental ;
-5. définir les archétypes de jeux et leurs besoins : reflex/arcade, snake/grid, puzzle/adventure, racing, fighting 1v1, hack'n slash, multiplayer compétitif, MMORPG/PKE et autres besoins déjà identifiés ;
-6. distinguer capability générique, système de jeu réutilisable et logique spécifique à un jeu ;
-7. définir le modèle de composition statique des produits et éviter de faire reposer toute la composition sur des Cargo features globales ;
-8. concevoir un manifest machine-readable de produit/jeu décrivant capabilities requises, optionnelles, non supportées, dépendantes d'un serveur ou spécifiques à une plateforme ;
-9. définir l'architecture cible des crates sans créer immédiatement toutes les crates réservées ;
-10. définir la stratégie de logging/tracing par domaines de crates et la configuration statique de build par produit/plateforme ;
-11. définir les frontières auth/identity, online/offline, persistence/sync, ads/providers, leaderboards, multiplayer, assets/CDN et services Web ;
-12. étudier explicitement le POC Tauri Android en comparaison de SDL Android ;
-13. remplacer à terme l'orchestration Android Python du POC par un outil/build system multi-ABI conçu pour le projet ;
-14. seulement après validation de cette conception, proposer la roadmap détaillée `0.2.x`, puis les orientations `0.3.x` et suivantes.
 
-## Exemples de pression architecturale
+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 ;
+- statuts ROADMAP `( )`, `(x)`, `(d)`, `(c)` ;
+- comportement d'un scope partiellement réalisé, reporté ou annulé ;
+- rôle du CHANGELOG limité aux jalons RC et stables ;
+- 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.
+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 ;
-### Adventure/puzzle à énergie
+3. définir les couches et dépendances autorisées ;
-
+4. établir la matrice plateformes ;
-Considérer énergie, inventaire, progression/XP/niveaux, maps/tiles, Sokoban, pipes, lasers/mirrors, rewarded ads, événements et classement.
+5. formaliser les archétypes de jeux servant de pression architecturale ;
-
+6. définir la composition statique et le manifest produit/jeu ;
-### Racing / fighting / hack'n slash / MMORPG-PKE
+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 ;
-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.
+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.
-## Livrables de conception attendus
-
-Créer au minimum, sous réserve de validation des noms pendant la session :
-
-```text
-docs/architecture/CAPABILITY_CATALOG.md
-docs/architecture/LAYERING_AND_DEPENDENCIES.md
-docs/architecture/PLATFORM_CAPABILITY_MATRIX.md
-docs/games/GAME_ARCHETYPES_AND_REQUIREMENTS.md
-```
-
-Le catalogue doit pouvoir attribuer à une capability un statut tel que `Reserved`, `Planned`, `Experimental`, `Implemented`, `PlatformSpecific`, `Unsupported(platform)` ou `Deprecated` sans que la simple réservation déclenche une implémentation.
 
 ## Contraintes
 
 - ne pas transformer `engine-v1` en moteur monolithique ;
-- conserver le gameplay portable indépendant des APIs de providers et plateformes ;
+- ne pas créer une crate pour chaque idée ;
-- préférer des contrats explicites et des adaptateurs aux `#[cfg]` dispersés dans les jeux ;
+- ne pas considérer une idée comme une capability réservée ;
-- ne pas charger dynamiquement des bibliothèques sans besoin démontré ;
+- ne pas figer une API purement spéculative ;
-- garder la composition statique Rust comme défaut ;
+- conserver le gameplay indépendant des APIs de providers et plateformes ;
-- ne pas figer prématurément une API ou une crate pour une fonctionnalité purement spéculative ;
+- préférer la composition statique Rust par produit ;
-- distinguer disponibilité, désactivation volontaire et non-support d'une capability ;
+- ne pas faire des Cargo features globales le système principal de composition ;
-- permettre qu'un jeu soit mono-plateforme, multi-plateforme, offline-only, online-optional ou online-required ;
+- permettre qu'un jeu ne cible qu'une partie des plateformes ;
-- respecter toutes les règles de version, audit, tests, fichiers et livraisons du dépôt.
+- 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.