pgr/ROADMAP.md

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 ;
• ( ) 0.0.5 — réconciliation réelle de PGR avec khadhroony-solana-project et sasedev-games, incluant la consolidation du lifecycle inter-release et de la revue d'horizon.

Première baseline réutilisable

• ( ) 0.1.0 — première baseline PGR destinée à initialiser de nouveaux projets à partir de règles, templates et skeleton specifications éprouvés.

Horizon après 0.1.0

L'horizon est volontairement ouvert. PGR ne réserve pas encore 0.1.1, 0.2.0 ou une autre release sans objectif suffisamment décidé.

Trajectoire explicitement différée

• (d) skeleton Tauri pour projets contrôlés — la décision 0.0.5-alpha.9 conserve le candidat, mais sa matérialisation attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS et leur validation. Aucun numéro de release n'est réservé pour ce travail et 0.1.0 ne doit pas le considérer comme obligatoire par défaut.

Cette entrée conserve une décision de report réelle ; elle ne transforme pas les autres candidats d'horizon en engagements. Les profils techniques supplémentaires, les projets documentaires/spécifications et l'audit de généricité hors logiciel restent chez leurs owners actuels tant qu'une revue d'horizon n'a pas décidé leur entrée dans la trajectoire engagée.

Le plan de 0.1.0 devra programmer une revue d'horizon avant sa clôture, à un moment où la première baseline réutilisable sera assez établie pour juger la suite. Cette revue pourra se tenir dans une session stratégique séparée sans modifier VERSION. Elle décidera soit d'étendre la présente roadmap, soit de maintenir explicitement l'horizon ouvert avec un nouveau déclencheur de revue, soit de requalifier/différer/mettre en pause une trajectoire concerné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.