77 lines
4.0 KiB
Markdown
77 lines
4.0 KiB
Markdown
<!-- file: prompts/001-V0_2_0_START_PROMPT.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# 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.
|