0.0.1-alpha.1

docs/architecture/001-PROJECT_PROFILE.md

@@ -0,0 +1,47 @@
+<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
+<!-- version: 1 -->
+
+# Profil du projet PGR
+
+## Rôle
+
+Le dépôt `pgr` est un référentiel de gouvernance et de documentation technique. Il n'est actuellement ni une application, ni une bibliothèque runtime, ni un projet Python applicatif.
+
+## Profils applicables
+
+```text
+GENERAL GOVERNANCE
+DOCUMENTATION
+VALIDATION GOVERNANCE
+GIT / RELEASE WORKFLOW
+MARKDOWN
+PYTHON 3 UTILITY SCRIPTS (uniquement lorsque des audits/outils apparaissent)
+```
+
+La présence future de scripts `audit_*.py` ne transforme pas PGR en package ou application Python.
+
+## Profils actuellement non applicables
+
+La première release de fondation n'applique pas encore les profils suivants au dépôt lui-même :
+
+```text
+RUST / CARGO
+JAVA / MAVEN / GRADLE
+ANDROID
+TAURI
+WEB APPLICATION
+WASM
+PHP / COMPOSER
+PYTHON APPLICATION/PACKAGE
+C / C++ / CMAKE
+```
+
+Ces technologies peuvent être documentées ultérieurement comme règles/templates/skeletons sans devenir des dépendances techniques du dépôt PGR.
+
+## Nomenclature et langue
+
+Les chemins, noms de fichiers, identifiants et éléments techniques sont en anglais. La documentation normative et explicative du dépôt principal est en français.
+
+## Baseline de gouvernance
+
+PGR se gouverne lui-même à partir de `0.0.1-alpha.1`. Le bootstrap initial part d'un dépôt vide ; il n'existe aucun faux tag, aucune fausse release `0.0.0` et aucune archive stable antérieure à simuler.

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`.