0.1.0-0-pre.3

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Documentation games.sasedev
 
@@ -42,3 +42,5 @@ Voir [`../RULES.md`](../RULES.md), notamment [`rules/RULES_COMMANDS.md`](rules/R
 ## Validation
 
 - [`validation/001-VALIDATION_GATES.md`](validation/001-VALIDATION_GATES.md) — gates manuelles du workspace.
+
+- [`development/002-DESKTOP_DISTRIBUTIONS.md`](development/002-DESKTOP_DISTRIBUTIONS.md) — distributions Desktop natives et variante Tauri optionnelle.

docs/development/001-DESKTOP_RUNNERS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/development/001-DESKTOP_RUNNERS.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Runners Desktop de développement
 
@@ -29,6 +29,10 @@ La crate lib du jeu porte gameplay, règles, état, progression et interfaces n
 
 Le runner Desktop ne remplace pas les tests Android. Lifecycle, JNI, tactile réel, Ads, Billing, haptique, permissions et APIs Play nécessitent une validation sur la cible Android.
 
-## Baseline `0.1.0-0-pre.2`
+## Baseline `0.1.0-0-pre.3`
 
-Les deux runners sont volontairement minimaux : ils lient les crates de jeu et permettent de vérifier leur exécution locale. La vraie boucle SDL3 Desktop reste planifiée dans une tranche dédiée.
+Les deux runners utilisent désormais le `FixedStepRunner` commun et des `InputState` logiques pour exercer la première boucle moteur indépendante de SDL. Ils déclarent explicitement la monétisation désactivée pour leur smoke Desktop.
+
+La traduction clavier/souris vers `InputState`, la fenêtre et le rendu SDL3 restent planifiés pour `0-pre.4`.
+
+La possibilité d'une variante Desktop Tauri est documentée séparément dans `002-DESKTOP_DISTRIBUTIONS.md` et reste optionnelle.

docs/development/002-DESKTOP_DISTRIBUTIONS.md

@@ -0,0 +1,53 @@
+<!-- file: docs/development/002-DESKTOP_DISTRIBUTIONS.md -->
+<!-- version: 1 -->
+
+# Distributions Desktop
+
+## Principe
+
+Le terme `Desktop` peut désigner plusieurs hôtes différents autour d'une même crate de jeu. Ces hôtes ne sont pas tous obligatoires et ne doivent jamais provoquer une duplication du gameplay.
+
+## Binaire natif SDL3
+
+Le runner natif est la voie Desktop canonique pour les jeux eux-mêmes :
+
+```text
+game lib
+   ↓
+engine V1
+   ↓
+SDL3
+   ↓
+native desktop binary
+```
+
+Il fournit la boucle de fenêtre, le rendu, l'audio et les entrées clavier/souris/gamepad nécessaires au jeu. C'est aussi la voie privilégiée pour les itérations rapides depuis le poste de développement.
+
+Convention initiale :
+
+```text
+crates/apps/<game>-desktop
+```
+
+## Variante Tauri optionnelle
+
+Une variante Tauri peut être ajoutée si un besoin réel apparaît : launcher, gestion de compte, configuration riche, catalogue de jeux, téléchargement de contenu, interface Web complexe ou application compagnon.
+
+Tauri utilise un backend Rust et une interface rendue dans une WebView. Cette architecture est différente du runner SDL3 natif et n'est pas une dépendance obligatoire du moteur.
+
+Si un jeu possède réellement deux distributions Desktop, la convention envisagée est :
+
+```text
+crates/apps/<game>-desktop
+crates/apps/<game>-desktop-tauri
+```
+
+La seconde n'est créée que lorsqu'elle apporte une fonctionnalité qui justifie son coût de maintenance.
+
+## Règle de non-duplication
+
+Les deux hôtes, s'ils coexistent, consomment la même crate lib de jeu. Le gameplay, le scoring, les règles et la progression ne sont jamais recopiés dans Tauri ou dans le runner natif.
+
+## Choix par défaut
+
+Pour les POC de jeux 2D, le binaire natif SDL3 est la cible Desktop par défaut. Tauri reste une extension future et ne fait pas partie de la gate initiale du moteur.

docs/monetization/001-MONETIZATION.md

@@ -1,45 +1,72 @@
 <!-- file: docs/monetization/001-MONETIZATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Monétisation
 
-## Principe d'abstraction
+## Principe
 
-Le gameplay ne dépend pas directement d'AdMob, AppLovin, LevelPlay ou d'un autre fournisseur. Il consomme un contrat de publicité ou de billing, tandis que l'implémentation Android passe par Java/JNI et les SDK natifs Android.
+La monétisation est une capacité optionnelle de plateforme et de distribution. Aucun jeu, aucune génération du moteur et aucun runner ne doit supposer qu'une publicité, un achat intégré ou un fournisseur particulier est disponible.
+
+Le gameplay dépend uniquement de contrats abstraits et doit rester fonctionnel lorsque la monétisation est `Disabled` ou `Unsupported`.
 
 ```text
-Rust game
-   ↓
-Advertising/Billing API
-   ↓
-platform implementation
-   ↓
-Java/JNI Android
-   ↓
-provider SDK
+Game
+ ↓
+Monetization contract
+ ↓
+capability state
+ ├── Available   -> backend plateforme
+ ├── Disabled    -> fonctionnalité volontairement coupée
+ └── Unsupported -> aucune implémentation pour cette cible
 ```
 
+## Android
+
+Android est la cible prioritaire pour la monétisation publicitaire des premiers jeux. L'implémentation prévue passe par Java/JNI et un fournisseur ou médiateur Android tel qu'AdMob, AppLovin MAX ou LevelPlay.
+
+La présence des SDK publicitaires n'est pas obligatoire dans toutes les variantes Android. Un build de test, une édition payante ou une distribution particulière peut désactiver la publicité tout en réutilisant exactement la même crate de jeu.
+
+## Web
+
+La monétisation Web est distincte de la monétisation Android. Un frontend Web peut utiliser ultérieurement un fournisseur publicitaire destiné aux sites ou contenus Web, par exemple une solution de type AdSense, mais il ne doit pas être traité comme une simple réutilisation du SDK AdMob Android.
+
+Le backend Web de monétisation reste optionnel et n'est introduit que lorsqu'une vraie cible Web est mise en œuvre et que ses contraintes de politique, consentement, sandbox navigateur et expérience utilisateur ont été validées.
+
+## Desktop natif
+
+Aucun fournisseur publicitaire Desktop générique n'est imposé par le framework. La baseline Desktop native considère la publicité comme désactivée par défaut.
+
+Une distribution Desktop peut préférer d'autres modèles : achat unique, donation, DLC, contenu premium, distribution via un store, cross-promotion externe ou absence totale de monétisation.
+
+Si un fournisseur publicitaire Desktop pertinent est retenu ultérieurement, il devra être ajouté derrière le même contrat optionnel sans faire entrer son SDK dans les crates de gameplay.
+
+## Desktop Tauri
+
+Un éventuel frontend Tauri peut techniquement afficher du contenu Web dans une WebView, mais cela ne transforme pas automatiquement une application Desktop en inventaire publicitaire Web autorisé. Toute solution publicitaire utilisée dans une WebView devra être vérifiée explicitement auprès du fournisseur concerné avant intégration.
+
+Tauri n'est donc pas une stratégie de contournement pour utiliser une régie Web dans un binaire Desktop.
+
 ## Publicités récompensées
 
 Usages possibles : seconde chance, revive, bonus x2, coffre gratuit, accélération, skin temporaire, monnaie supplémentaire, nouveau tirage ou poursuite d'une série.
 
-La récompense n'est accordée qu'après réception de l'événement plateforme indiquant que la condition publicitaire requise est satisfaite.
+La logique de jeu doit prévoir un chemin normal lorsque la publicité récompensée est indisponible. Une récompense publicitaire n'est accordée qu'après réception de l'événement de succès défini par le backend actif.
 
 ## Interstitiels
 
 Les emplacements naturels sont entre deux parties, après plusieurs manches, à la fin d'un niveau ou après un écran de résultats. Ils ne doivent pas interrompre arbitrairement une action en cours.
 
-## Achat de suppression des publicités
+## Suppression des publicités
 
-Une option `remove ads` peut supprimer les publicités non récompensées tout en laissant éventuellement disponibles les rewarded ads volontaires.
+Une option `remove ads` peut supprimer les publicités non récompensées tout en laissant éventuellement disponibles les rewarded ads volontaires. Cette politique appartient à la distribution et au jeu, pas au moteur commun.
 
-## Autres achats
+## Billing et achats
 
-Des achats ou déblocages peuvent concerner skins, personnages, cosmétiques ou packs. Les achats numériques doivent respecter les règles de facturation de la plateforme de distribution utilisée.
+Des achats ou déblocages peuvent concerner skins, personnages, cosmétiques ou packs. Le backend de billing est lui aussi optionnel et spécifique à la plateforme de distribution.
 
 ## Médiation
 
-Une plateforme de médiation peut agréger plusieurs demandes publicitaires. Cette architecture ne doit pas remonter dans le gameplay : le moteur manipule placements, disponibilité, affichage, fermeture, récompense et erreurs, pas le réseau publicitaire gagnant.
+Une plateforme de médiation peut agréger plusieurs demandes publicitaires. Cette architecture ne remonte pas dans le gameplay : le moteur manipule disponibilité, placement, affichage, fermeture, récompense et erreurs, pas le réseau publicitaire gagnant.
 
 ## Configuration distante
 

docs/rules/RULES_COMMANDS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_COMMANDS.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Règles d'exécution des commandes
 
@@ -11,6 +11,10 @@
 - **CMD-GEN-004** — Une gate n'est déclarée réussie que si la commande exacte a été exécutée sur l'état livré.
 - **CMD-GEN-005** — Les commandes ciblées sont préférées pendant le développement ; les commandes workspace complètes sont utilisées aux gates de livraison.
 - **CMD-GEN-006** — Les scripts `audit_*` sont des contrôles en lecture seule et ne corrigent jamais automatiquement les fichiers.
+- **CMD-GEN-007** — Sauf demande explicite contraire, les commandes Cargo de validation finale sont exécutées par l'utilisateur sur son workspace local et non déclarées réussies par le générateur.
+- **CMD-GEN-008** — Chaque fichier delta indique les commandes de validation que l'utilisateur doit exécuter et le statut connu de la validation du delta précédent.
+- **CMD-GEN-009** — Lorsque l'utilisateur fournit une gate complète propre, le delta est considéré validé et le travail peut passer automatiquement au delta planifié suivant sauf instruction contraire.
+- **CMD-GEN-010** — Si une gate échoue, la progression vers le delta suivant est suspendue ; le correctif est livré sous le suffixe `.fix.N` du delta courant, sauf décision explicite contraire.
 
 ## Rust et Cargo
 
@@ -32,6 +36,8 @@
 - **CMD-DESKTOP-002** — Le runner Desktop dépend de la crate lib du jeu et ne duplique pas le gameplay.
 - **CMD-DESKTOP-003** — Le runner Desktop est la voie privilégiée pour les itérations fonctionnelles rapides qui ne nécessitent pas une capacité Android spécifique.
 - **CMD-DESKTOP-004** — Un test Android reste obligatoire pour toute fonctionnalité dépendant du lifecycle, du tactile réel, de JNI, d'Ads, de Billing, de haptique ou d'une API Android.
+- **CMD-DESKTOP-005** — Le runner Desktop natif SDL3 est la distribution Desktop de jeu par défaut. Une variante Tauri est optionnelle, distincte et n'est créée que pour un besoin explicite.
+- **CMD-DESKTOP-006** — Une variante Tauri dépend de la même crate lib de jeu et ne duplique jamais le gameplay du runner natif.
 
 ## Android et Gradle
 

docs/rules/RULES_PROJECT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/RULES_PROJECT.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Règles spécifiques games.sasedev
 
@@ -46,6 +46,9 @@
 - **GAME-PLATFORM-001** — Le gameplay ne dépend pas directement d'Android, Desktop ou Web.
 - **GAME-PLATFORM-002** — Les entrées physiques sont traduites en actions de jeu abstraites.
 - **GAME-PLATFORM-003** — Les services Ads, Billing, Share, Haptics, Leaderboard et stockage en ligne sont consommés derrière des contrats plateforme.
+- **GAME-PLATFORM-004** — Ads et Billing sont des capacités optionnelles ; le gameplay reste fonctionnel lorsqu'elles sont disponibles, désactivées ou non supportées.
+- **GAME-PLATFORM-005** — Un backend de monétisation est spécifique à sa plateforme et à sa distribution ; une intégration Android n'est pas réutilisée implicitement sur Web ou Desktop.
+- **GAME-PLATFORM-006** — Le runner Desktop natif SDL3 est la forme Desktop par défaut. Une variante Tauri peut coexister uniquement lorsqu'un besoin explicite le justifie et consomme la même crate lib de jeu.
 
 ## POC
 

docs/validation/001-VALIDATION_GATES.md

@@ -1,9 +1,17 @@
 <!-- file: docs/validation/001-VALIDATION_GATES.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Gates de validation
 
-Gate Rust et documentation canonique :
+## Responsabilité
+
+Les audits Python peuvent être exécutés pendant la préparation d'un delta. Sauf demande explicite contraire, les commandes Cargo finales sont exécutées par l'utilisateur sur le workspace local.
+
+Le générateur ne marque jamais une commande Cargo comme propre s'il ne dispose que du résultat d'un delta antérieur.
+
+## Gate canonique Rust et documentation
+
+À exécuter par l'utilisateur pour valider chaque delta contenant du code, du build, des manifests ou des règles affectant le workspace :
 
 ```bash
 cargo fmt --all -- --check
@@ -14,13 +22,25 @@ cargo clippy --workspace --all-targets --all-features -- -D warnings
 cargo test --workspace --all-targets --all-features
 ```
 
-Smokes Desktop ciblés lorsque le comportement exécutable concerné doit être observé :
+## Smokes Desktop
+
+Lorsqu'un delta modifie la boucle exécutable, le runtime ou le comportement visible des runners Desktop, exécuter également :
 
 ```bash
 cargo run -p game-reflex-poc-desktop
 cargo run -p game-snake-poc-desktop
 ```
 
-Les smokes `cargo run` ne remplacent pas la gate de tests et ne sont pas obligatoires pour une modification purement documentaire.
+Les smokes `cargo run` ne remplacent pas la gate de tests.
 
-Le build Android n'est pas encore une gate : le projet Gradle exécutable et l'intégration SDL3/NDK restent planifiés pour une prerelease dédiée. Dès leur introduction, les tâches ciblées par module seront documentées avant d'être rendues obligatoires.
+## Transition vers le delta suivant
+
+Si toutes les commandes demandées sont propres, le delta courant est validé et le travail peut passer automatiquement au prochain delta de la roadmap, sauf avis contraire de l'utilisateur.
+
+Si une commande échoue, ne pas avancer de prerelease. Produire un correctif du delta courant, par exemple `0.1.0-0-pre.3.fix.1`, puis rejouer la gate demandée.
+
+## Android et Web
+
+Le build Android n'est pas encore une gate : le projet Gradle exécutable et l'intégration SDL3/NDK restent planifiés pour une prerelease dédiée. Dès leur introduction, les tâches ciblées par module sont documentées avant d'être rendues obligatoires.
+
+La cible Web suit la même règle : aucune gate Web n'est inventée avant l'existence de son build réel.