4.4 KiB
Roadmap Project Governance Rules
Le roadmap décrit le découpage macro engagé des releases PGR. Il ne remplace ni les objectifs globaux du projet ni les plans détaillés de version et ne sert pas à inventer des versions futures uniquement pour prolonger l'horizon.
Statuts : ( ) planifié, (x) terminé, (d) différé, (c) annulé.
Fondation 0.0.x
(x) 0.0.1— fondation normative et documentaire : gouvernance, lifecycle des releases, rôles documentaires, workflow delta/history/handoff et validation proportionnée ;(x) 0.0.2— premiers profils de règles réutilisables : Rust/Cargo, Java/Maven/Gradle et Android, avec modèle de composition et audits Markdown initiaux ;(x) 0.0.3— templates techniques initiaux et premiers patterns d'audit réutilisables issus de besoins réels ;(x) 0.0.4— spécifications Markdown de skeletons et règles de composition des profils/templates ;(x) 0.0.5— réconciliation réelle de PGR aveckhadhroony-solana-projectetsasedev-games, incluant la consolidation du lifecycle inter-release et de la revue d'horizon.
Première baseline réutilisable
(x) 0.1.0— première baseline PGR destinée à initialiser de nouveaux projets et à adopter progressivement des projets existants à partir de règles, templates, skeleton specifications et validations éprouvés.
Trajectoire engagée 0.1.x
La revue d'horizon de 0.1.0-beta.1 engage les releases suivantes, chacune avec un domaine cohérent et une session/release indépendante :
(x) 0.1.1— fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ;(x) 0.1.2— réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ;(x) 0.1.3— réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;(x) 0.1.4— domaine Tauri : réexamen duDEFER, consolidation de l’owner710, matérialisation du skeleton contrôlé004et décision explicite de ne pas créer d’artefacts techniques redondants ;( ) 0.1.5— sémantique normative et autonomie : clarifierMUST / SHOULD / MAY, rendre explicite l’autorité locale d’un projet après instanciation/adoption et fixer la frontière durable entre PGR et SaseDev Knowledge ;( ) 0.1.6— adoption réelle de PGR parsasedev-gamesavec mappingADOPT / KEEP-LOCAL / OVERRIDE / DEFER, après stabilisation du contrat d’autonomie ;( ) 0.1.7— adoption réelle de PGR parkhadhroony-solana-project, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;( ) 0.1.8— audits Python read-only d’un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacercargo clippy.
Le détail et les conditions de cette séquence sont conservés dans docs/studies/003-V0_1_0_HORIZON_REVIEW.md.
Trajectoires différées ou non numérotées
WASM— candidat séparé à réévaluer pendant l'adoption Games si un owner PGR apporte une valeur immédiate ;serveur Web Rust / Actix Web ou alternative— candidat à partir d'un corpus d'implémentation réel, pas sur la seule base d'une trajectoire roadmap ;saselang-bible, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure0.2.x/0.3.xà décider ;deployment & operations— famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon0.4.xou0.5.xest plausible mais aucun numéro précis n'est réservé.
La revue d’horizon 0.1.4-rc.1 remplace l’ordre initial 0.1.5 Games / 0.1.6 KSP / 0.1.7 audits par le contrat ci-dessus. Une nouvelle revue d’horizon doit intervenir si 0.1.5 démontre que l’autonomie ne peut pas être stabilisée sans scope supplémentaire, ou si Games/KSP exigent un owner réellement préalable à une adoption proportionnée.
Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant alpha.1.