# 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`, `history/0.1.0/3-rc.1.fix.1.md` et `deltas/0.1.0/rel.md` avant toute proposition. ## Principe de la version `0.2.0` est une version de conception et de réservation architecturale. 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. Les audits Markdown ou de règles valident la forme mais ne valent jamais validation humaine du fond. ## Ordre de travail ### `0-pre.1` — gouvernance documentaire Fixer avant le catalogue fonctionnel : - 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. Ne pas encore figer le catalogue complet des capabilities dans cette étape. ### `0-pre.2` et suivantes — conception fonctionnelle progressive Après validation humaine de la gouvernance documentaire : 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 ; - 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. ## Validation Chaque prerelease documentaire est livrée comme delta relisible. 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.