pgr/README.md

Project Governance Rules

Project Governance Rules (PGR) est un référentiel réutilisable de gouvernance, développement, validation et structuration de projets logiciels.

Son objectif est de normaliser ce qui mérite de l'être, de simplifier les workflows récurrents, d'automatiser les contrôles fiables et de conserver une traçabilité utile sans transformer la gouvernance en bureaucratie.

Le dépôt officiel est https://git.sasedev.com/Sasedev/pgr.

Statut

La stable autoritaire courante reste 0.1.4. La candidate 0.1.5-rc.1 gèle désormais les trois contrats transversaux réconciliés : SHOULD / SHOULD NOT reste une forte recommandation non obligatoire, la baseline locale d’un projet devient son autorité après instanciation/adoption avec réalignement PGR uniquement explicite, et PGR reste auto-suffisant face aux contenus pratiques externes possibles de SaseDev Knowledge. La revue d’horizon limitée confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption Games : 0.1.6 reste la prochaine release, suivie de KSP 0.1.7 puis des audits Rust/Clippy 0.1.8, sans réservation de 0.1.9.

La version courante est définie par VERSION. La release 0.0.1 établit la gouvernance normative et documentaire de PGR lui-même. La release 0.0.2 ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release 0.0.3 fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release 0.0.4 définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils 500 + 510 et les cinq templates existants. La release 0.0.5 réconcilie PGR avec les baselines réelles de khadhroony-solana-project et sasedev-games : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release 0.1.0 stabilise la première baseline réutilisable : adoption ADOPT / KEEP-LOCAL / OVERRIDE / DEFER, skeletons/templates Rust/Cargo exercés par dry-run, clôture rel.N, handoff opérateur automatique et trajectoire 0.1.1 à 0.1.7 issue d'une revue d'horizon explicite. La release 0.1.1 stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en DEFER jusqu’à son réexamen 0.1.4. La release 0.1.2 stabilise trois owners indépendants 520-JAVA, 521-MAVEN et 522-GRADLE, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans 610-ANDROID.md pour leur réévaluation distincte en 0.1.3. La release 0.1.3 stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release 0.1.4 stabilise le domaine Tauri : owner 710 recentré sur host/orchestration/ACL/plugins, skeleton 004 composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers 0.1.5 pour clarifier la sémantique normative et l’autonomie des projets.

Entrées principales

• RULES.md — point d'entrée normatif ;
• ROADMAP.md — découpage macro des releases PGR ;
• CHANGELOG.md — changements des releases publiées ;
• docs/000-README.md — index documentaire ;
• docs/objectives/001-PROJECT_OBJECTIVES.md — mission, objectifs et non-objectifs ;
• docs/architecture/001-PROJECT_PROFILE.md — profil applicable au dépôt PGR ;
• docs/architecture/002-GOVERNANCE_ARCHITECTURE.md — architecture du référentiel ;
• docs/plans/001-V0_0_1_FOUNDATION_PLAN.md — plan historique de fondation 0.0.1 ;
• docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md — plan historique des premiers profils 0.0.2 ;
• docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md — plan historique des templates et audits 0.0.3 ;
• docs/plans/004-V0_0_4_SKELETONS_PLAN.md — plan historique des skeleton specifications 0.0.4 ;
• docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md — plan historique de réconciliation 0.0.5 ;
• docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md — plan historique de la première baseline réutilisable 0.1.0 ;
• docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md — plan historique de la fondation frontend Web stable 0.1.1 ;
• docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md — plan historique de la stable 0.1.2 : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
• docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md — plan historique de la stable Android 0.1.3, fondée sur Games avec classification ADOPT / KEEP-LOCAL / OVERRIDE / DEFER ;
• docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md — plan historique de la stable Tauri 0.1.4, du réexamen Games/KSP au skeleton 004, à la décision d’artefacts et à la revue d’horizon ;
• docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md — plan actif 0.1.5 : sémantique normative, autonomie locale, frontière PGR / Knowledge et réconciliation transversale avant les adoptions Games/KSP ;
• docs/skeletons/004-TAURI.md — specialization Tauri 2 composable, sans template technique universel ni defaults de capabilities/plugins/fenêtres/bundles ;
• docs/studies/001-KSP_GAMES_RECONCILIATION.md — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
• docs/skeletons/000-README.md — index des skeleton specifications et de leur contrat de composition ;
• docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md — fondation composable de gouvernance locale pour un projet adoptant PGR ;
• docs/skeletons/002-RUST_CARGO_WORKSPACE.md — specialization composable pour un workspace Rust/Cargo gouverné ;
• docs/skeletons/003-WEB_FRONTEND.md — specialization composable pour un frontend Web contrôlé, avec TypeScript/Vite recommandés, Sass optionnel et validation indépendante du host ;
• docs/validation/001-VALIDATION_MATRIX.md — matrice de validation.

Langue et nomenclature

Les noms de fichiers, répertoires, identifiants, code et configurations utilisent l'anglais. Les explications et la documentation normative du dépôt principal utilisent le français.

Une éventuelle traduction complète de PGR doit vivre dans un dépôt séparé, par exemple pgr-en, pgr-de ou pgr-ar, et non dans une arborescence multilingue du dépôt principal.