0.1.0

prompts/001-V0_2_0_START_PROMPT.md

@@ -0,0 +1,84 @@
+<!-- file: prompts/001-V0_2_0_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.2.0 — conception 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.
+
+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.
+
+## Objectif
+
+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.
+
+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.
+
+## Travail de conception obligatoire
+
+Effectuer les étapes suivantes dans cet ordre, avec discussion/audit avant gel :
+
+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.
+
+## Exemples de pression architecturale
+
+Utiliser des jeux concrets pour tester la conception, sans les implémenter tous immédiatement.
+
+### Snake
+
+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.
+
+### Reflex
+
+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.
+
+## 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.
+
+## Résultat attendu de la première session 0.2.0
+
+La session doit d'abord produire une architecture documentée cohérente et une roadmap d'implémentation progressive.
+
+Le développement fonctionnel significatif ne commence qu'après validation de cette conception.