0.1.5-alpha.3

docs/rules/230-ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/230-ADOPTION.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Existing project adoption rules
 
@@ -17,7 +17,7 @@ PGR s’adapte au besoin réel du projet existant ; il ne cherche pas à effacer
 
 Une adoption MUST partir d’une baseline autoritaire réellement observée : commit, tag, archive de release ou autre état explicitement accepté par le projet. Le travail d’adoption MUST distinguer ce qui existe déjà de ce que PGR propose d’ajouter ou de modifier.
 
-Une migration réussie produit un projet autonome gouverné localement. Le projet destinataire ne devient pas dépendant runtime ou build du dépôt PGR.
+Une migration réussie produit un projet autonome gouverné localement. Une fois la baseline locale établie, elle devient l'autorité des sessions et releases suivantes du projet. Le projet destinataire ne devient pas dépendant runtime, build ou documentaire implicite du dépôt PGR et MUST NOT rechercher automatiquement « la dernière version de PGR ».
 
 ## Audit initial de la baseline
 
@@ -98,6 +98,22 @@ Les conventions nouvelles s’appliquent à partir du point d’adoption explici
 
 Une adoption MAY documenter des écarts hérités comme dette, exception temporaire ou contexte historique sans modifier les snapshots qui les ont produits.
 
+## Autorité locale et réalignement futur
+
+Après clôture du scope d'adoption, les règles, plans, décisions, validations et historiques locaux gouvernent les travaux suivants. Les sessions et releases ultérieures MUST partir de cette baseline locale et non d'une recherche automatique d'une version PGR plus récente.
+
+PGR n'est pas un upstream documentaire implicite. Une référence, URL ou archive PGR utilisée pendant l'adoption reste une source de comparaison de cette opération ; elle ne crée pas un abonnement aux évolutions futures du référentiel. Une dépendance documentaire externe MAY exister uniquement si le projet la choisit et la possède explicitement comme contrat local.
+
+Un réalignement futur avec PGR MAY être engagé lorsqu'il apporte une valeur réelle. Cette opération MUST être explicite et bornée. Elle doit au minimum :
+
+1. identifier le snapshot PGR choisi, par exemple version, tag, commit ou archive ;
+2. repartir de la baseline locale autoritaire du projet ;
+3. comparer les owners applicables et classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+4. définir le scope et les validations de la migration ;
+5. préserver les histories, tags et décisions historiques au lieu de les réécrire pour simuler une conformité continue.
+
+Le réalignement ne doit pas être présenté comme une mise à jour automatique. Entre deux opérations explicitement décidées, la gouvernance locale reste autonome et suffisante pour reprendre le projet.
+
 ## Relation avec les skeletons et templates
 
 Un skeleton PGR MAY servir de checklist de comparaison pour un projet existant. Il ne doit pas être appliqué comme si le dépôt était vide.
@@ -118,7 +134,7 @@ Une adoption n’est terminée que lorsque les décisions de son scope sont clas
 
 Une adoption PGR réussie laisse :
 
-- un projet autonome ;
+- un projet autonome dont la baseline locale gouverne les sessions et releases suivantes ;
 - uniquement les owners PGR réellement applicables ;
 - les choix locaux légitimes préservés ;
 - les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;