0.1.0-alpha.4

2026-09-26 19:31:22 +02:00
parent 351025b4f2
commit e4b5992266
10 changed files with 598 additions and 8 deletions
--- a/RULES.md
+++ b/RULES.md
@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 11 -->
+<!-- version: 12 -->

 # Index normatif Project Governance Rules

@@ -77,6 +77,7 @@ Familles actuellement actives :
 - [`docs/rules/200-GOVERNANCE.md`](docs/rules/200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.
 - [`docs/rules/210-WORKFLOW.md`](docs/rules/210-WORKFLOW.md) — plans, deltas, histories, prompts, handoffs, manifests, commits, baselines et reprise de session.
 - [`docs/rules/220-SKELETONS.md`](docs/rules/220-SKELETONS.md) — sélection, composition, adaptation et validation des skeleton specifications.
+- [`docs/rules/230-ADOPTION.md`](docs/rules/230-ADOPTION.md) — adoption proportionnée de PGR par un projet existant, mapping des owners, décisions locales et migration progressive.
 - [`docs/rules/300-DOCUMENTATION.md`](docs/rules/300-DOCUMENTATION.md) — rôles documentaires, taxonomie, révisions internes, documents vivants et conservation historique.
 - [`docs/rules/400-VALIDATION.md`](docs/rules/400-VALIDATION.md) — sélection proportionnelle des preuves, catégories de validation, tests utiles, doubles de test et autorité opérateur.
 - [`docs/rules/500-LANGUAGES.md`](docs/rules/500-LANGUAGES.md) — contrat commun des profils langage, écosystème et spécialisations de build associées.
--- a/2
+++ b/2
@@ -1 +1 @@
-0.1.0-alpha.3.fix.1
+0.1.0-alpha.4
--- a/deltas/0.1.0/alpha.4.md
+++ b/deltas/0.1.0/alpha.4.md
@@ -0,0 +1,232 @@
+<!-- file: deltas/0.1.0/alpha.4.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.4 — adoption PGR d’un projet existant
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.3.fix.1`, réalisé après application de `history/0.1.0/alpha.3.fix.1.md` avec statut `PASS`.
+
+Le hash de ce commit n’est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.3.fix.1
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.4
+```
+
+## Objet
+
+Formaliser le contrat d’adoption de PGR par un projet existant, distinct de l’instanciation d’un nouveau projet.
+
+La tranche introduit :
+
+- un owner normatif `230-ADOPTION.md` ;
+- un pattern documentaire `007-EXISTING_PROJECT_ADOPTION.md` ;
+- la représentation architecturale du flux d’adoption ;
+- les index nécessaires pour rendre ces artefacts découvrables ;
+- le mapping canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- la préservation explicite de l’historique antérieur au point d’adoption.
+
+Cette tranche ne migre ni Games ni KSP. Elle ne crée aucun nouveau profil Web, Android, Tauri, WASM ou serveur.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+RULES.md
+docs/000-README.md
+docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+docs/rules/000-README.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/alpha.4.md
+docs/rules/230-ADOPTION.md
+docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+DELETE : aucun.
+
+Les profils technologiques, skeletons existants, scripts d’audit, tests et `ROADMAP.md` restent inchangés.
+
+## Décisions normatives
+
+### Adoption distincte de l’instanciation
+
+Un projet existant part de sa baseline réelle. Un skeleton MAY servir de référence de comparaison, mais PGR ne prétend pas que le dépôt a été créé depuis ce skeleton.
+
+L’adoption ne doit pas imposer toute la bibliothèque PGR ni réécrire l’historique pour simuler une conformité passée.
+
+### Classification canonique
+
+Chaque owner ou contrat candidat dans le scope d’adoption est classifié selon :
+
+```text
+ADOPT
+KEEP-LOCAL
+OVERRIDE
+DEFER
+```
+
+`KEEP-LOCAL` préserve une décision locale qui n’a pas besoin d’être remplacée. `OVERRIDE` remplace ou raffine explicitement une règle PGR applicable et doit porter scope et justification. `DEFER` enregistre un report réel et ne peut pas être présenté comme une adoption terminée.
+
+### Migration progressive
+
+L’adoption SHOULD être découpée en tranches validables et proportionnées lorsque cela réduit le risque. L’adoption d’un profil n’entraîne pas automatiquement celle des profils voisins.
+
+Les conventions nouvelles commencent au point d’adoption établi ; les commits, tags, histories et autres snapshots antérieurs restent historiques.
+
+## Validation opérateur
+
+Après application du history `PASS`, commit/push de `alpha.3.fix.1`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.4'
+git cat-file -e HEAD:history/0.1.0/alpha.3.fix.1.md
+test -f history/0.1.0/alpha.3.fix.1.md
+test -f deltas/0.1.0/alpha.4.md
+test -f docs/rules/230-ADOPTION.md
+test -f docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+test ! -e history/0.1.0/alpha.4.md
+
+grep -A2 '^## Statut$' history/0.1.0/alpha.3.fix.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 12 -->' RULES.md
+grep -Fx '<!-- version: 14 -->' docs/rules/000-README.md
+grep -Fx '<!-- version: 20 -->' docs/000-README.md
+grep -Fx '<!-- version: 4 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -Fx '<!-- version: 1 -->' docs/rules/230-ADOPTION.md
+grep -Fx '<!-- version: 1 -->' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+grep -Fx '<!-- version: 6 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+history = Path('history/0.1.0/alpha.3.fix.1.md').read_text(encoding='utf-8')
+rules = Path('RULES.md').read_text(encoding='utf-8')
+rules_index = Path('docs/rules/000-README.md').read_text(encoding='utf-8')
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+architecture = Path('docs/architecture/002-GOVERNANCE_ARCHITECTURE.md').read_text(encoding='utf-8')
+adoption = Path('docs/rules/230-ADOPTION.md').read_text(encoding='utf-8')
+template = Path('docs/templates/007-EXISTING_PROJECT_ADOPTION.md').read_text(encoding='utf-8')
+plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+
+assert re.search(r'## Statut\s+PASS\s', history)
+
+for phrase in (
+    'ADOPT',
+    'KEEP-LOCAL',
+    'OVERRIDE',
+    'DEFER',
+    'baseline autoritaire',
+    'Migration progressive',
+    'Préservation de l’historique',
+    'MUST NOT demander de réécrire des commits, tags, histories, changelogs',
+    'Un skeleton PGR MAY servir de checklist de comparaison pour un projet existant.',
+    '../templates/007-EXISTING_PROJECT_ADOPTION.md',
+):
+    assert phrase in adoption, phrase
+
+for phrase in (
+    '## Baseline autoritaire',
+    '## Mapping d’adoption',
+    'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
+    '## Découpage de migration',
+    '## Historique et compatibilité',
+    '## Validation de sortie',
+):
+    assert phrase in template, phrase
+
+for phrase in (
+    '## Adoption d’un projet existant',
+    'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
+    'projet autonome avec historique préservé',
+    '../rules/230-ADOPTION.md',
+):
+    assert phrase in architecture, phrase
+
+assert 'docs/rules/230-ADOPTION.md' in rules
+assert '230-ADOPTION.md' in rules_index
+assert 'rules/230-ADOPTION.md' in index
+assert 'templates/007-EXISTING_PROJECT_ADOPTION.md' in index
+assert 'Statut opérateur : **PASS**.' in plan
+assert 'Statut opérateur : **à valider**.' in plan
+assert 'Cette tranche ne migre ni Games ni KSP.' in Path('deltas/0.1.0/alpha.4.md').read_text(encoding='utf-8')
+assert '- `( ) 0.1.1`' not in roadmap
+
+print('0.1.0 alpha.4 existing-project adoption audit: clean (baseline, owner mapping, decision classes, progressive migration and history preservation explicit)')
+PYGATE
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_markdown_headers.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+python3 -B scripts/audit_markdown_tables.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+python3 -B scripts/audit_markdown_links.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+
+git diff --check
+
+git add VERSION RULES.md docs/000-README.md \
+    docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    docs/rules/000-README.md docs/rules/230-ADOPTION.md \
+    docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
+    deltas/0.1.0/alpha.4.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history de `alpha.4` est exactement :
+
+```text
+M  RULES.md
+M  VERSION
+A  deltas/0.1.0/alpha.4.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/rules/000-README.md
+A  docs/rules/230-ADOPTION.md
+A  docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le contrat d’adoption n’impose pas tous les profils PGR à un projet existant ;
+- `KEEP-LOCAL` n’est pas utilisé comme alias silencieux d’un override ;
+- `OVERRIDE` exige bien scope et justification ;
+- `DEFER` reste distinct d’un résultat adopté ;
+- un skeleton sert seulement de référence de comparaison lorsqu’il est utile ;
+- aucun historique du projet destinataire ne doit être réécrit pour rendre le passé rétroactivement conforme ;
+- Games et KSP restent des futurs consommateurs, pas des dépendances de `0.1.0` ;
+- aucun numéro futur `0.1.x` n’est réservé par cette tranche.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.4.md`, l’appliquer puis remettre automatiquement les commandes de commit/push conformément à `210-WORKFLOW.md` et `006-OPERATOR_COMMAND_HANDOFF.md`.
+
+Reprendre ensuite la trajectoire avec `0.1.0-alpha.5`, consacré à la réconciliation de la fondation, du skeleton Rust/Cargo et au dry-run de composition/adoption.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.0/alpha.4.md` et rester dans `alpha.4.fix.N` sauf REPLAN justifié. Le fix MUST rester borné au défaut réellement observé.
--- a/docs/000-README.md
+++ b/docs/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 19 -->
+<!-- version: 20 -->

 # Documentation PGR

@@ -24,6 +24,8 @@ Les templates techniques copiables sous `templates/` restent séparés des instr

 - [`plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — audit de la stable `v0.0.5`, cadrage du workflow de clôture/publication et préparation de la première baseline PGR réellement réutilisable.
 - [`templates/006-OPERATOR_COMMAND_HANDOFF.md`](templates/006-OPERATOR_COMMAND_HANDOFF.md) — pattern de remise automatique des commandes entre history, commit/push, delta suivant, tag et vérification post-tag.
+- [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) — contrat d’adoption proportionnée de PGR par un projet existant sans réécriture rétroactive de son historique.
+- [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — pattern court de baseline, mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, découpage et validation d’une migration existante.

 ## Points d'entrée de 0.0.5

--- a/docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+++ b/docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->

 # Architecture de gouvernance PGR

@@ -55,6 +55,26 @@ PGR rules + templates + skeleton specifications

 Une évolution ultérieure de PGR ne modifie jamais automatiquement les projets déjà créés.

+## Adoption d’un projet existant
+
+Un dépôt déjà existant ne repasse pas artificiellement par le flux d’instanciation. Son adoption part de sa baseline réelle et compare les owners PGR applicables avec les contrats locaux avant toute migration. Le mapping utilise la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`.
+
+Le flux conceptuel est :
+
+```text
+baseline autoritaire du projet
+            ↓
+inventaire + owners PGR applicables
+            ↓
+ADOPT / KEEP-LOCAL / OVERRIDE / DEFER
+            ↓
+migration progressive + validation
+            ↓
+projet autonome avec historique préservé
+```
+
+Le contrat normatif appartient à [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md). Un skeleton MAY servir de référence de comparaison, mais l’adoption ne prétend pas que le projet existant a été créé depuis ce skeleton et ne réécrit pas rétroactivement ses snapshots historiques.
+
 ## Hiérarchie

 Les règles générales sont raffinées par les scopes plus spécifiques. Un choix spécialisé, par exemple une contrainte Tauri Android, ne devient pas automatiquement une règle Android ou Java générale.
--- a/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+++ b/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->

 # Plan 0.1.0 — première baseline PGR réutilisable

@@ -197,13 +197,21 @@ La gate spécifique n'a toutefois pas pu s'exécuter jusqu'au bout : le littéra

 ### alpha.3.fix.1 — correction de la gate du handoff opérateur

-Corriger uniquement la syntaxe du contrôle Python de `alpha.3`, conserver les owners et le delta historique inchangés, puis reconfirmer le handoff automatique, les tests, audits Markdown et le scope minimal du fix.
+Statut opérateur : **PASS**.
+
+Le fix a conservé `210-WORKFLOW.md`, `006-OPERATOR_COMMAND_HANDOFF.md`, l'index documentaire et le delta historique `alpha.3.md` inchangés. La gate corrigée a reconfirmé le `FAIL` historique de `alpha.3`, le contenu normatif du handoff et le pattern opérateur.
+
+La validation a exécuté `48/48` tests et les trois audits Markdown sans diagnostic. Aucun nouveau fix ni REPLAN n'est requis.

 ### alpha.4 — adoption d'un projet existant

+Statut opérateur : **à valider**.
+
 Formaliser une méthode courte d'adoption PGR pour un dépôt existant : audit de la baseline réelle, mapping des owners applicables, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, migration progressive et interdiction de réécrire l'historique uniquement pour le rendre rétroactivement conforme.

-Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet.
+Le nouvel owner `230-ADOPTION.md` doit distinguer explicitement adoption et instanciation par skeleton. Le pattern `007-EXISTING_PROJECT_ADOPTION.md` doit fournir une forme réutilisable sans devenir un manifest obligatoire.
+
+Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet ni migrer effectivement ces dépôts dans `0.1.0`.

 ### alpha.5 — baseline réutilisable et dry-run de composition

--- a/docs/rules/000-README.md
+++ b/docs/rules/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/000-README.md -->
-<!-- version: 13 -->
+<!-- version: 14 -->

 # Index des règles PGR

@@ -14,6 +14,7 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
 - [`200-GOVERNANCE.md`](200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.
 - [`210-WORKFLOW.md`](210-WORKFLOW.md) — contrats des artefacts workflow, ordre delta/history/commit, prompts versionnés, reprise et baselines de release.
 - [`220-SKELETONS.md`](220-SKELETONS.md) — contrat commun des skeleton specifications, sélection des profils/templates, décisions, overrides et validation.
+- [`230-ADOPTION.md`](230-ADOPTION.md) — contrat d’adoption PGR pour un dépôt existant, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et migration incrémentale.
 - [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques.
 - [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur.
 - [`500-LANGUAGES.md`](500-LANGUAGES.md) — contrat commun des profils langage/écosystème et de leurs spécialisations de build.
--- a/docs/rules/230-ADOPTION.md
+++ b/docs/rules/230-ADOPTION.md
@@ -0,0 +1,127 @@
+<!-- file: docs/rules/230-ADOPTION.md -->
+<!-- version: 1 -->
+
+# Existing project adoption rules
+
+## Scope
+
+Ce document définit le contrat transversal d’adoption de PGR par un projet **déjà existant**. Il couvre la reprise d’une baseline réelle, l’inventaire des owners applicables, la comparaison avec les contrats locaux, la classification des décisions d’adoption, la migration progressive, les exceptions et la validation de l’état obtenu.
+
+L’adoption d’un dépôt existant est distincte de l’instanciation d’un nouveau projet par skeleton. Les skeleton specifications restent possédées par [`220-SKELETONS.md`](220-SKELETONS.md) ; l’adoption peut les utiliser comme référence de composition sans prétendre recréer rétroactivement le projet.
+
+Les règles de workflow et de validation restent respectivement possédées par [`210-WORKFLOW.md`](210-WORKFLOW.md) et [`400-VALIDATION.md`](400-VALIDATION.md).
+
+## Principe
+
+PGR s’adapte au besoin réel du projet existant ; il ne cherche pas à effacer l’histoire du dépôt ni à imposer toute la bibliothèque de profils disponible.
+
+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.
+
+## Audit initial de la baseline
+
+Avant de modifier le projet, l’adoption MUST établir au minimum :
+
+- la baseline autoritaire et son niveau de confiance ;
+- les règles, conventions, outils, fichiers de gouvernance et validations déjà présents ;
+- les langages, plateformes, frameworks et autres profils réellement applicables ;
+- les contraintes locales qui ne doivent pas être remplacées par une règle générique ;
+- les incohérences ou dettes qui nécessitent une décision au lieu d’une conversion automatique.
+
+L’audit SHOULD réutiliser les outils du projet et les audits PGR applicables lorsqu’ils sont disponibles. Il MUST NOT interpréter l’absence d’un artefact PGR comme un défaut en soi tant qu’aucune règle applicable ne l’exige.
+
+## Mapping des owners applicables
+
+L’adoption MUST sélectionner les owners PGR à partir du scope réel du dépôt. Elle MUST NOT activer tous les profils PGR par défaut.
+
+Chaque owner ou contrat candidat à l’adoption doit être comparé avec l’état local avant décision. Un profil non applicable reste hors scope ; une technologie envisagée mais non encore présente MAY rester `DEFER`.
+
+Les owners PGR servent de référence normative pour ce qui est réellement adopté. Les règles propres au projet restent locales et ne deviennent pas automatiquement des règles générales PGR.
+
+## Classification des décisions
+
+Le mapping d’adoption utilise les quatre classifications suivantes :
+
+```text
+ADOPT
+KEEP-LOCAL
+OVERRIDE
+DEFER
+```
+
+### ADOPT
+
+`ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
+
+L’adoption MAY être immédiate ou découpée en plusieurs tranches si le changement est trop large pour être validé proprement en une fois.
+
+### KEEP-LOCAL
+
+`KEEP-LOCAL` signifie qu’un contrat local existant reste préférable ou nécessaire et qu’il n’entre pas en contradiction avec une obligation PGR réellement adoptée.
+
+Cette classification ne crée pas une exception : elle reconnaît qu’un choix local demeure hors du besoin de normalisation ou qu’un owner PGR ne possède pas ce détail.
+
+### OVERRIDE
+
+`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée 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.
+
+### DEFER
+
+`DEFER` signifie qu’une décision applicable est volontairement différée parce qu’un prérequis, un owner, une preuve ou une priorité manque encore.
+
+Le report SHOULD indiquer ce qui permettrait de reprendre la décision. `DEFER` MUST NOT être présenté comme une adoption accomplie.
+
+## Migration progressive
+
+L’adoption SHOULD privilégier des tranches cohérentes et validables. Une migration massive n’est justifiée que si elle apporte moins de risque et de coût qu’une progression incrémentale.
+
+Une tranche d’adoption SHOULD :
+
+1. identifier le sous-ensemble de décisions concerné ;
+2. modifier uniquement les owners locaux, configurations, templates ou structures nécessaires ;
+3. appliquer une validation proportionnée aux contrats réellement modifiés ;
+4. enregistrer les décisions durables chez leurs owners locaux ;
+5. laisser les domaines non concernés inchangés.
+
+L’adoption d’un profil ne force pas l’adoption simultanée des profils voisins. Par exemple, un dépôt Rust utilisant Tauri peut adopter les règles Rust/Cargo disponibles tout en différant les owners Web encore insuffisants.
+
+## Préservation de l’historique
+
+PGR MUST NOT demander de réécrire des commits, tags, histories, changelogs ou autres snapshots historiques uniquement pour donner l’apparence d’une conformité rétroactive.
+
+Les conventions nouvelles s’appliquent à partir du point d’adoption explicitement établi. Les artefacts historiques restent interprétés selon leur contexte d’origine, sauf correction exceptionnelle justifiée par une erreur factuelle ou un risque réel.
+
+Une adoption MAY documenter des écarts hérités comme dette, exception temporaire ou contexte historique sans modifier les snapshots qui les ont produits.
+
+## 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.
+
+Lorsqu’un template PGR est pertinent, l’adoption MUST comparer sa responsabilité et ses valeurs avec le fichier local avant remplacement. Un fichier local fonctionnel ne doit pas être écrasé uniquement pour obtenir une copie identique au template PGR.
+
+Une différence locale MAY être conservée si elle relève d’une décision du projet, d’un `KEEP-LOCAL` ou d’un `OVERRIDE` valide.
+
+## Validation de l’adoption
+
+Chaque étape d’adoption MUST sélectionner des preuves proportionnées selon [`400-VALIDATION.md`](400-VALIDATION.md).
+
+La validation SHOULD d’abord prouver que le projet reste fonctionnel dans son environnement réel, puis que les nouveaux contrats de gouvernance ou de structure sont respectés. Un audit PGR read-only ne remplace pas une toolchain ou un smoke autoritaire lorsqu’un contrat appartient à cette toolchain ou à cet environnement.
+
+Une adoption n’est terminée que lorsque les décisions de son scope sont classifiées, les changements retenus sont appliqués, les validations requises sont acquises et les `DEFER` restants sont explicitement hors du scope déclaré.
+
+## Résultat attendu
+
+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 domaines différés clairement identifiés ;
+- un historique non falsifié ;
+- une validation proportionnée au changement réellement effectué.
+
+[`../templates/007-EXISTING_PROJECT_ADOPTION.md`](../templates/007-EXISTING_PROJECT_ADOPTION.md) fournit un pattern documentaire court pour préparer et suivre ce mapping sans imposer un format de migration unique.
--- a/docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+++ b/docs/templates/007-EXISTING_PROJECT_ADOPTION.md
@@ -0,0 +1,97 @@
+<!-- file: docs/templates/007-EXISTING_PROJECT_ADOPTION.md -->
+<!-- version: 1 -->
+
+# Pattern — adoption PGR d’un projet existant
+
+## Usage
+
+Ce pattern aide à préparer une adoption PGR sur un dépôt existant conformément à [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md). Il n’est pas un manifest obligatoire, un générateur de migration ni un remplacement du plan de release local.
+
+Il peut être instancié comme étude, plan, tableau de décision ou section d’un document existant si le projet a besoin d’une trace durable. Un petit alignement dont les décisions sont évidentes MAY rester directement documenté dans le delta et le history correspondants.
+
+## Baseline autoritaire
+
+Consigner uniquement ce qui est réellement établi :
+
+```text
+repository / archive : <source>
+commit / tag          : <si connu>
+version               : <si applicable>
+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.
+
+## Inventaire utile
+
+Identifier les éléments qui déterminent l’applicabilité :
+
+- gouvernance et workflow déjà présents ;
+- langages et build systems réellement utilisés ;
+- plateformes et frameworks présents ;
+- validations et scripts existants ;
+- contraintes locales ou historiques à préserver ;
+- profils PGR sans rapport avec le dépôt, explicitement hors scope si leur confusion est probable.
+
+## Mapping d’adoption
+
+La classification canonique est `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`. La forme exacte du mapping reste libre. Une table courte peut suffire :
+
+```text
+Owner / contrat        État local        Décision      Action / justification
+--------------------   ----------------  ------------  -----------------------
+<RULE/PGR owner>       <état observé>    ADOPT         <migration ciblée>
+<contrat local>        <état observé>    KEEP-LOCAL    <raison>
+<RULE/PGR owner>       <état observé>    OVERRIDE      <scope + raison>
+<RULE/PGR owner>       <état observé>    DEFER         <prérequis / déclencheur>
+```
+
+Les quatre décisions ont le sens normatif défini par `230-ADOPTION.md`. Ne pas créer une cinquième catégorie uniquement pour éviter de décider si un point est adopté, local, overridé ou différé.
+
+## Découpage de migration
+
+Pour chaque tranche réellement nécessaire, préciser :
+
+```text
+scope            : <owners / fichiers / contrats concernés>
+hors scope       : <domaines laissés intacts>
+risque principal : <ce qui pourrait être cassé>
+preuve            : <gate proportionnée>
+```
+
+Le découpage SHOULD favoriser des changements vérifiables indépendamment. Une migration ne doit pas embarquer une technologie future uniquement parce qu’un profil PGR existe.
+
+## Historique et compatibilité
+
+Noter les conventions qui commencent au point d’adoption et les snapshots historiques qui doivent rester inchangés.
+
+Exemples :
+
+```text
+- ancienne nomenclature de tags conservée avant <point d’adoption> ;
+- anciennes règles locales conservées dans les histories ;
+- nouvelle convention appliquée uniquement aux prochaines tranches ;
+- dette héritée documentée mais non réécrite rétroactivement.
+```
+
+## Validation de sortie
+
+L’adoption du scope est prête lorsque :
+
+- chaque owner candidat du scope est classifié ;
+- les changements `ADOPT` sont réellement appliqués ;
+- les `KEEP-LOCAL` et `OVERRIDE` sont compréhensibles et possédés localement ;
+- les `DEFER` ont un motif et restent hors du résultat présenté comme terminé ;
+- les validations nécessaires ont réussi ;
+- le projet reste autonome par rapport au dépôt PGR.
+
+## Limites
+
+Ce pattern ne décide pas à la place du projet :
+
+- quels profils sont applicables ;
+- si Games, KSP ou un autre dépôt doit migrer maintenant ;
+- si une règle locale doit devenir une règle PGR générale ;
+- si une migration doit occuper une ou plusieurs releases.
+
+Ces décisions appartiennent au contexte réel du projet et à son plan actif.
--- a/history/0.1.0/alpha.4.md
+++ b/history/0.1.0/alpha.4.md
@@ -0,0 +1,102 @@
+<!-- file: history/0.1.0/alpha.4.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.4 — adoption PGR d’un projet existant
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-alpha.4` exécutée le `2026-09-26` a réussi. Le contrat d’adoption d’un projet existant, son pattern documentaire, leur indexation et leur représentation architecturale ont été validés sans migration effective de Games ou KSP.
+
+## Baseline opérateur
+
+La tranche `0.1.0-alpha.3.fix.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `alpha.4` :
+
+```text
+commit       351025b
+message      0.1.0-alpha.3.fix.1
+push         origin/master PASS
+```
+
+Après application du delta `alpha.4`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.4
+history/0.1.0/alpha.3.fix.1.md                      présent dans HEAD et le workspace
+deltas/0.1.0/alpha.4.md                             présent
+docs/rules/230-ADOPTION.md                          version 1
+docs/templates/007-EXISTING_PROJECT_ADOPTION.md     version 1
+RULES.md                                            version 12
+docs/rules/000-README.md                            version 14
+docs/000-README.md                                  version 20
+docs/architecture/002-GOVERNANCE_ARCHITECTURE.md   version 4
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 6
+history/0.1.0/alpha.4.md                            absent pendant la gate
+```
+
+Le history précédent a été retrouvé avec statut `PASS`.
+
+## Validation opérateur observée
+
+Le contrôle structurel ciblé a terminé proprement :
+
+```text
+0.1.0 alpha.4 existing-project adoption audit: clean (baseline, owner mapping, decision classes, progressive migration and history preservation explicit)
+```
+
+Il confirme notamment :
+
+- le mapping canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- la baseline autoritaire comme point de départ d’une adoption ;
+- la migration progressive et proportionnée ;
+- la préservation explicite de l’historique ;
+- l’usage d’un skeleton comme checklist de comparaison plutôt que comme copie aveugle ;
+- l’indexation des nouveaux owners et patterns ;
+- l’absence de réservation prématurée d’une future `0.1.1`.
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.723s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (186 file(s))
+Markdown table audit: clean (8 table(s), 186 file(s))
+Markdown link audit: clean (178 local link(s), 186 file(s))
+```
+
+## Contrôles Git
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  RULES.md
+M  VERSION
+A  deltas/0.1.0/alpha.4.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/rules/000-README.md
+A  docs/rules/230-ADOPTION.md
+A  docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+Le scope correspond exactement au delta annoncé.
+
+## Décision
+
+`0.1.0-alpha.4` est `PASS`. Aucun fix ni REPLAN n’est requis.
+
+La trajectoire normale reprend à :
+
+```text
+0.1.0-alpha.5
+```
+
+Cette tranche réconcilie la fondation de gouvernance, le skeleton Rust/Cargo, les templates techniques et la validation minimale, puis exerce deux dry-runs : instanciation d’un nouveau workspace Rust et adoption non destructive d’un workspace Rust existant synthétique.