0.0.1-alpha.1

docs/architecture/002-GOVERNANCE_ARCHITECTURE.md

@@ -0,0 +1,82 @@
+<!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
+<!-- version: 1 -->
+
+# 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`.