# Architecture de gouvernance PGR ## Principe général PGR sépare quatre familles d'artefacts qui ne doivent pas être confondues. ### Rule Une règle définit un contrat normatif. Elle explique ce qui est obligatoire, interdit, attendu ou autorisé dans un scope donné. La règle est la source normative ; un template ou un audit ne crée pas une règle par sa seule existence. ### Template Un template fournit une baseline technique réutilisable, par exemple une configuration de formatter, linter, compilateur ou build tool. Un template implémente des règles déjà documentées. Il peut être copié tel quel ou adapté selon les instructions du skeleton applicable. Après instanciation, le projet possède sa copie et ne dépend plus de PGR. ### Skeleton specification Un skeleton est une recette Markdown décrivant comment initialiser un type de projet ou composer plusieurs profils. Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base. Un skeleton n'est pas un générateur et ne doit pas figer l'évolution future du projet. ### Audit Un audit contrôle une propriété structurelle réellement automatisable. Les scripts `audit_*.py` sont read-only : ils ne modifient, ne formatent, ne génèrent, n'installent, ne téléchargent et ne lancent pas les toolchains du projet inspecté. Les audits PGR sont ajoutés progressivement à partir de besoins réels et de contrôles éprouvés. PGR ne cherche pas à anticiper un catalogue exhaustif d'audits. ## Instanciation d'un projet Le flux conceptuel est : ```text PGR rules + templates + skeleton specifications ↓ sélection humaine / IA ↓ nouveau projet ↓ copies et règles locales ↓ projet autonome et gouverné ``` Une évolution ultérieure de PGR ne modifie jamais automatiquement les projets déjà créés. ## Hiérarchie Les règles générales sont raffinées par les scopes plus spécifiques. Un choix spécialisé, par exemple une contrainte Tauri Android, ne devient pas automatiquement une règle Android ou Java générale. Les règles project-specific restent dans le dépôt qui les possède. ## Structure de croissance PGR crée ses collections et familles de règles lorsque leur premier contenu réel apparaît. Les répertoires vides et les documents placeholders sont évités. Les futures familles pourront notamment couvrir : ```text general governance documentation validation languages platforms frameworks architecture project-specific rules ``` sans exiger leur matérialisation complète pendant `0.0.1-alpha.1`.