0.1.5-alpha.3

docs/templates/007-EXISTING_PROJECT_ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/007-EXISTING_PROJECT_ADOPTION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern — adoption PGR d’un projet existant
 
@@ -14,13 +14,14 @@ Il peut être instancié comme étude, plan, tableau de décision ou section d
 Consigner uniquement ce qui est réellement établi :
 
 ```text
-repository / archive : <source>
+repository / archive : <source locale autoritaire>
 commit / tag          : <si connu>
 version               : <si applicable>
+snapshot PGR choisi   : <version / tag / commit / archive de comparaison>
 validation connue     : <preuves déjà acquises et encore pertinentes>
 ```
 
-Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR.
+Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR. Le snapshot PGR est une entrée de comparaison explicitement choisie pour cette opération ; il n'est pas un upstream que le projet doit suivre ensuite.
 
 ## Inventaire utile
 
@@ -74,6 +75,20 @@ Exemples :
 - dette héritée documentée mais non réécrite rétroactivement.
 ```
 
+
+## Autorité après adoption
+
+À la clôture du scope, consigner explicitement que la baseline locale obtenue devient l'autorité des sessions et releases suivantes. Une forme courte suffit :
+
+```text
+baseline locale autoritaire : <version / commit / état accepté>
+réalignement PGR automatique : non
+```
+
+Les reprises ultérieures partent des règles, plans, architecture et histories du projet. Elles ne recherchent pas automatiquement « la dernière version de PGR ».
+
+Si un réalignement futur est souhaité, ouvrir une nouvelle opération bornée : choisir un snapshot PGR précis, comparer ses owners applicables à la baseline locale, classifier les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis valider seulement le scope retenu. Les snapshots historiques locaux restent inchangés.
+
 ## Validation de sortie
 
 L’adoption du scope est prête lorsque :