Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.5-alpha.2

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-10-01 09:53:53 +02:00
parent 32433caccf
commit e94b78610d
15 changed files with 406 additions and 65 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/rules/230-ADOPTION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/230-ADOPTION.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Existing project adoption rules
@@ -50,6 +50,8 @@ OVERRIDE
DEFER
```
Ces classifications n'augmentent pas la force normative d'une règle. En particulier, choisir une solution différente d'un `SHOULD` / `SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire ; le projet MAY conserver ce choix comme décision locale et documenter sa raison lorsque cette trace apporte une valeur durable.
### ADOPT
`ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
@@ -64,9 +66,9 @@ Cette classification ne crée pas une exception : elle reconnaît qu’un choix
### OVERRIDE
`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée dans un scope local.
`OVERRIDE` signifie qu'une obligation PGR réellement applicable, ou un contrat localement rendu obligatoire, est volontairement remplacé ou raffiné dans un scope local.
L’override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue.
L'override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue. Un simple écart à une recommandation `SHOULD` / `SHOULD NOT` MUST NOT exiger un override uniquement parce que la recommandation n'est pas suivie.
### DEFER
@@ -119,7 +121,7 @@ Une adoption PGR réussie laisse :
- un projet autonome ;
- uniquement les owners PGR réellement applicables ;
- les choix locaux légitimes préservés ;
- les overrides explicites ;
- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;
- les domaines différés clairement identifiés ;
- un historique non falsifié ;
- une validation proportionnée au changement réellement effectué.