6.4 KiB
Modèle de profils de règles PGR
Rôle
Un profil PGR est un ensemble cohérent de règles réutilisables dont le scope est plus spécifique que les règles générales.
Un profil ne constitue ni un catalogue de dépendances, ni un template technique, ni un skeleton de projet. Il définit uniquement les règles durables réellement propres à un langage, un écosystème, une plateforme, un framework, un type de projet ou un sous-système.
Les règles générales restent héritées implicitement. Elles ne sont pas recopiées dans chaque profil.
Axes de spécialisation
La composition normative suit l'ordre général :
GENERAL
↓
ecosystem / language
↓
platform
↓
framework
↓
project type / subsystem
↓
project-specific
↓
explicit exception
Cet ordre exprime la spécificité des scopes. Il ne signifie pas qu'un projet doit posséder un profil à chaque niveau.
Un projet peut par exemple combiner uniquement :
GENERAL
+ Rust / Cargo
ou :
GENERAL
+ Java
+ Gradle
+ Android
Une technologie absente du projet ne rend aucun profil correspondant applicable.
Propriétaire normatif
Toute règle durable doit posséder un seul propriétaire normatif canonique.
Lorsqu'une règle est déjà correctement possédée par un document général, un profil spécifique doit la référencer si nécessaire, mais ne doit pas la recopier sous une formulation équivalente.
Inversement, une contrainte réellement propre à un profil ne doit pas être remontée vers un owner général uniquement pour réduire le nombre de fichiers.
Le propriétaire est choisi selon le scope le plus général dans lequel la règle reste vraie sans exception implicite.
Applicabilité
Un profil doit rendre son scope explicite : l'utilisateur ou le skeleton futur doit pouvoir déterminer à partir de faits du projet si le profil s'applique.
L'applicabilité doit reposer sur des propriétés concrètes, par exemple :
- langage ou écosystème réellement utilisé ;
- build tool réellement utilisé ;
- plateforme réellement ciblée ;
- framework réellement présent ;
- type de projet ou sous-système réellement concerné.
PGR ne doit pas appliquer un profil uniquement parce qu'il est fréquent, recommandé ailleurs ou présent dans un projet source historique.
Composition et résolution
La résolution d'un ensemble de profils suit ces étapes :
- appliquer les règles générales ;
- ajouter les profils langage/écosystème applicables ;
- ajouter les profils plateforme applicables ;
- ajouter les profils framework applicables ;
- ajouter les profils de type de projet ou sous-système applicables ;
- appliquer les règles propres au projet ;
- appliquer les exceptions explicites et bornées.
Une règle plus spécifique peut raffiner, renforcer ou remplacer une règle plus générale dans son scope.
Lorsqu'elle contredit volontairement une règle héritée, le profil spécifique doit identifier l'override, son scope et sa raison. L'ordre des fichiers dans un répertoire ne crée jamais une priorité normative.
Deux règles applicables de même niveau qui se contredisent sans relation explicite ne sont pas départagées arbitrairement : la situation constitue un défaut de conformité ou de modélisation à résoudre.
Spécialisation interne à une famille
Une famille peut posséder plusieurs niveaux internes lorsque cela réduit la duplication.
Par exemple, un profil de langage peut être complété par un build tool particulier :
Java
↓
Maven
ou :
Java
↓
Gradle
Cette relation interne ne modifie pas la hiérarchie globale. Une contrainte de plateforme plus spécifique peut encore raffiner le résultat lorsqu'elle s'applique.
Lorsque langage et build tool sont pratiquement indissociables pour le scope visé, PGR peut les documenter dans un même profil si cette fusion évite une séparation artificielle. Le choix du découpage doit suivre les responsabilités réelles, pas une taxonomie rigide.
Profils composites
PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.
Un profil composite n'est justifié que lorsque l'intersection de plusieurs profils possède des règles propres qui ne peuvent être correctement possédées par chacun séparément.
Ainsi, la simple coexistence de Rust et Android ne suffit pas à créer un profil Rust + Android. Un tel profil devient pertinent seulement lorsqu'un contrat propre à leur interaction, par exemple une frontière FFI/JNI, doit être normé.
Choix ouverts
Un choix encore indécis n'est pas une règle.
Lorsqu'un profil révèle plusieurs options légitimes sans critère permettant d'en retenir une, PGR doit conserver la question comme décision ouverte, étude ou point de planification approprié plutôt que d'inventer une valeur par défaut arbitraire.
Une contrainte issue d'un framework, d'une plateforme ou d'un outil externe peut devenir une règle spécifique lorsque son caractère obligatoire est établi.
Non-duplication
Un profil doit contenir uniquement ce qui ajoute une information normative dans son scope.
Il ne doit pas recopier les règles générales relatives notamment à la gouvernance, aux documents, aux secrets, au lifecycle des releases ou à la validation lorsque ces règles s'appliquent déjà sans modification.
Une règle transversale découverte pendant la création de plusieurs profils doit être remontée vers un propriétaire commun uniquement si elle est réellement indépendante de ces profils.
Croissance documentaire
PGR matérialise uniquement les familles et profils possédant un contenu normatif réel.
Pour 0.0.2, les familles nécessaires sont :
500 — languages / ecosystems
600 — platforms
Les familles 700 — frameworks et 800 — architecture restent réservées tant qu'un premier profil réel ne justifie pas leur activation normative.
Le modèle architectural présent n'oblige pas à créer des fichiers placeholders pour les profils différés.
Instanciation future
Les futures skeleton specifications sélectionneront les profils applicables et recopieront leurs règles pertinentes dans la baseline locale du projet créé.
Le projet instancié restera autonome : la composition de profils sert à construire sa baseline initiale, pas à créer une dépendance dynamique vers PGR.