85 lines
3.1 KiB
Markdown
85 lines
3.1 KiB
Markdown
<!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# 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 principes généraux actuellement suffisants restent possédés par le `RULES.md` racine. Une famille dédiée `100 — general` n'est matérialisée que si un corpus général distinct devient réellement utile.
|
|
|
|
Les familles de croissance peuvent notamment couvrir :
|
|
|
|
```text
|
|
general
|
|
governance
|
|
documentation
|
|
validation
|
|
languages
|
|
platforms
|
|
frameworks
|
|
architecture
|
|
project-specific rules
|
|
```
|
|
|
|
Cette classification guide la navigation sans imposer la création anticipée de fichiers ou répertoires vides.
|