0.0.5-alpha.6.fix.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Modèle de profils de règles PGR
|
||||
|
||||
@@ -117,6 +117,16 @@ Cette relation interne ne modifie pas la hiérarchie globale. Une contrainte de
|
||||
|
||||
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.
|
||||
|
||||
## Baseline contrôlée et projet imposé
|
||||
|
||||
La même combinaison de technologies peut être gouvernée avec des degrés de liberté différents.
|
||||
|
||||
Pour une baseline créée et contrôlée par le projet, les profils sélectionnés s'appliquent intégralement puis une skeleton specification MAY fixer des choix réutilisables supplémentaires : layout, stack frontend, conventions de manifests ou organisation des fichiers.
|
||||
|
||||
Pour un projet existant ou imposé par un tiers, PGR doit d'abord préserver les contraintes externes réellement obligatoires. Toute divergence avec le profil préféré devient une règle project-specific ou une exception explicite et bornée ; elle ne modifie pas automatiquement le profil général.
|
||||
|
||||
Cette distinction évite deux erreurs opposées : forcer le skeleton interne d'une organisation sur un dépôt qu'elle ne contrôle pas, ou affaiblir ses propres conventions sous prétexte qu'un framework accepte plusieurs formes.
|
||||
|
||||
## Profils composites
|
||||
|
||||
PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.
|
||||
|
||||
Reference in New Issue
Block a user