0.2.0-0-pre.1

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 ;
-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 ;
+- 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.
-
-### 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 ;
+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.