0.1.5-alpha.3

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 48 -->
+<!-- version: 49 -->
 
 # Documentation PGR
 
@@ -22,10 +22,10 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 
 ## Points d'entrée de 0.1.5
 
-- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale, frontière PGR / Knowledge, réconciliation puis freeze.
+- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale `alpha.3`, frontière PGR / Knowledge, réconciliation puis freeze.
 - [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
 - [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires réconciliés en `alpha.2` : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, sans `FAIL` de gate ni `OVERRIDE` automatique pour un simple écart.
-- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — propagation du contrat d'autonomie après instanciation/adoption.
+- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — owners réconciliés en `alpha.3` : baseline locale autoritaire, absence d'upstream PGR implicite et réalignement volontaire fondé sur un snapshot choisi.
 - [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners proposés pour formaliser la frontière PGR / SaseDev Knowledge sans dépendance externe.
 - [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.
 

docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
 
@@ -214,22 +214,31 @@ frontière PGR / Knowledge
 
 Aucun nouveau owner Knowledge n’est prévu par défaut.
 
-## Progression acquise avant `alpha.2`
+## Progression acquise avant `alpha.3`
 
 La première gate `alpha.1` a acquis les tests et audits principaux mais n'a pas exécuté toutes les assertions contractuelles prévues par son delta. Son history conserve donc le résultat réel `PARTIAL`.
 
 `alpha.1.fix.1` a été limité à l'acquisition des preuves manquantes : trajectoire ROADMAP, frontière delta/history, assertions du prompt `011`, assertions du présent plan et audits documentaires. Cette récupération est `PASS` et n'a modifié aucun owner normatif.
 
-La tranche `alpha.2` peut donc appliquer la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications sont bornées aux owners et artefacts où l'inventaire a démontré un renforcement accidentel ou une référence vivante obsolète : `RULES.md`, `230`, `400`, `500`, `530`, `540`, `700`, le skeleton Web `003` et le guide `008`.
+La tranche `alpha.2` a ensuite appliqué la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications ont été bornées aux owners et artefacts où l'inventaire avait démontré un renforcement accidentel ou une référence vivante obsolète : `RULES.md`, `230`, `400`, `500`, `530`, `540`, `700`, le skeleton Web `003` et le guide `008`. Sa gate opérateur du `2026-10-01` est `PASS` avec `55/55` tests et les audits documentaires propres.
 
-Décisions de mise en œuvre `alpha.2` :
+Décisions acquises en `alpha.2` :
 
 - `SHOULD / SHOULD NOT` devient explicitement une forte recommandation non obligatoire ;
 - un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique ;
 - un projet MAY documenter la raison d'un écart lorsqu'elle apporte une valeur durable ;
 - les contradictions avec des obligations `MUST / MUST NOT` restent soumises aux contrats d'exception/override applicables ;
 - la référence vivante à l'adoption Games est corrigée de `0.1.5` vers `0.1.6` ;
-- l'autonomie post-adoption reste réservée à `alpha.3` et la frontière Knowledge à `alpha.4`.
+- l'autonomie post-adoption est mise en œuvre par `alpha.3` ; la frontière Knowledge reste réservée à `alpha.4`.
+
+Décisions de mise en œuvre `alpha.3` :
+
+- après instanciation ou adoption, la baseline locale et ses owners deviennent l'autorité des sessions/releases suivantes ;
+- PGR ne devient ni dépendance documentaire implicite ni upstream à suivre et aucun mécanisme ne doit rechercher automatiquement « la dernière version de PGR » ;
+- un réalignement futur exige une opération explicitement décidée et bornée, fondée sur un snapshot PGR précis choisi par le projet ;
+- ce réalignement compare le snapshot choisi à la baseline locale, reclassifie les écarts utiles et préserve les histories au lieu de mettre à jour silencieusement la gouvernance ;
+- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : leur contrat de reprise depuis la baseline autoritaire du projet est déjà compatible ;
+- la frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`.
 
 ## Trajectoire de release
 

docs/rules/220-SKELETONS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/220-SKELETONS.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Skeleton specification rules
 
@@ -23,7 +23,9 @@ Un skeleton MUST NOT devenir :
 - un moyen de figer une architecture au-delà du scope qu'il déclare ;
 - un catalogue de technologies ou de fichiers créés par anticipation.
 
-Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet.
+Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Cette baseline locale devient l'autorité de ses sessions et releases suivantes. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet et le projet MUST NOT rechercher automatiquement une version PGR plus récente.
+
+Un réalignement futur MAY être décidé explicitement. Il doit alors partir d'un snapshot PGR précis choisi par le projet, comparer ce snapshot à la baseline locale et appliquer uniquement les écarts explicitement retenus. Ce réalignement est une nouvelle opération bornée ; il ne transforme pas PGR en upstream documentaire permanent.
 
 ## Applicabilité
 

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 ;

docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Skeleton — Project governance foundation
 
@@ -70,7 +70,9 @@ Ce document doit au minimum :
 - expliquer la priorité ou la spécialisation locale lorsqu'une adaptation existe ;
 - renvoyer vers les documents détaillés au lieu de recopier leur contenu sans nécessité.
 
-Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable.
+Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi et possédé par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable et ne crée pas un upstream documentaire implicite.
+
+À l'issue de l'instanciation, la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes. Le projet MUST NOT rechercher automatiquement « la dernière version de PGR ». Un réalignement ultérieur MAY être entrepris uniquement comme opération explicite à partir d'un snapshot PGR précis choisi puis comparé à cette baseline locale.
 
 ### Version
 

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 :