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 :

inventorier les capabilities déjà justifiées par les jeux et plateformes envisagés ;
distinguer capability générique, système de jeu réutilisable et logique propre à un jeu ;
définir les couches et dépendances autorisées ;
établir la matrice plateformes en réservant notamment Linux, Windows, macOS, Android, iOS et Web sans confondre OS, classe de device et backend ;
formaliser les archétypes de jeux servant de pression architecturale ;
définir la composition statique et le manifest produit/jeu ;
définir l'architecture cible des crates sans les créer prématurément ;
traiter progressivement logging, auth/identity, online/offline, persistence/sync, ads/providers, leaderboards, multiplayer, assets/CDN et services Web ;
étudier Tauri Android par un futur POC comparatif sans décider à l'avance qu'il remplace SDL Android ;
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 :

audits syntaxiques propres ;
revue humaine explicite du contenu ;
corrections ou compléments demandés ;
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.

4.0 KiB Raw Blame History