0.1.0

0.1.0-rc.1
0.1.0-beta.1
2026-09-26 23:31:54 +02:00 · 2026-09-26 23:26:23 +02:00 · 2026-09-26 23:10:02 +02:00 · 2026-09-26 20:33:53 +02:00 · 2026-09-26 19:31:22 +02:00 · 2026-09-26 19:19:20 +02:00
44 changed files with 4630 additions and 31 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 9 -->
+<!-- version: 11 -->

 # Changelog Project Governance Rules

@@ -7,6 +7,15 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des

 Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.

+## 0.1.0
+
+- établit la première baseline PGR réellement réutilisable pour initialiser de nouveaux projets et adopter progressivement des projets existants, avec une fondation de gouvernance, des skeleton specifications composables et une validation proportionnée ;
+- stabilise le socle Rust/Cargo réutilisable : cinq templates techniques, composition `001 + 002`, dry-run `NEW` avec Cargo/rustfmt/Clippy et chemin `ADOPTION` non destructif ;
+- formalise l'adoption de projets existants avec baseline autoritaire, migration progressive et décisions `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, sans réécriture rétroactive de l'historique ;
+- corrige la convention de clôture stable vers `rel.N` sans zéro de padding et garantit que la première clôture qui obtient réellement `PASS` produit le commit produit `X.Y.Z` avant le tag `vX.Y.Z` ;
+- rend obligatoire le handoff automatique des commandes opérateur entre history, commit/push, delta suivant et publication stable, avec distinction entre objet tag, commit déréférencé et rapport `publish.*` post-tag ;
+- matérialise la revue d'horizon suivante : frontend Web, Java/Gradle, Android, Tauri conditionnel, adoption Games puis KSP et audits Rust/Clippy statiques Python-only, tout en laissant WASM, serveur Rust et deployment/operations sans réservation prématurée.
+
 ## 0.0.5

 - consolide le lifecycle inter-release de PGR : prompts de reprise versionnés, contrats locaux de fichiers/familles, responsabilités de fermeture et revue d'horizon sans création artificielle de releases futures ;
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 14 -->
+<!-- version: 16 -->

 # Project Governance Rules

@@ -11,9 +11,9 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.

 ## Statut

-PGR est actuellement en phase de fondation `0.0.x`.
+PGR a clôturé sa phase de fondation `0.0.x` et dispose avec `0.1.0` de sa première baseline réutilisable stable pour initialiser de nouveaux projets et adopter progressivement des projets existants.

-La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants.
+La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite.

 ## Entrées principales

@@ -29,6 +29,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
 - [`docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — plan historique des templates et audits `0.0.3` ;
 - [`docs/plans/004-V0_0_4_SKELETONS_PLAN.md`](docs/plans/004-V0_0_4_SKELETONS_PLAN.md) — plan historique des skeleton specifications `0.0.4` ;
 - [`docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md`](docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md) — plan historique de réconciliation `0.0.5` ;
+- [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la première baseline réutilisable `0.1.0` ;
 - [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
 - [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;
 - [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 8 -->
+<!-- version: 10 -->

 # Roadmap Project Governance Rules

@@ -17,18 +17,30 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.

 ## Première baseline réutilisable

- `( ) 0.1.0` — première baseline PGR destinée à initialiser de nouveaux projets à partir de règles, templates et skeleton specifications éprouvés.
+- `(x) 0.1.0` — première baseline PGR destinée à initialiser de nouveaux projets et à adopter progressivement des projets existants à partir de règles, templates, skeleton specifications et validations éprouvés.

-## Horizon après `0.1.0`
+## Trajectoire engagée `0.1.x`

-L'horizon est volontairement ouvert. PGR ne réserve pas encore `0.1.1`, `0.2.0` ou une autre release sans objectif suffisamment décidé.
+La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec un domaine cohérent et une session/release indépendante :

-### Trajectoire explicitement différée
+- `( ) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ;
+- `( ) 0.1.2` — réévaluation pratique du profil Java/Maven/Gradle existant et matérialisation des artefacts génériques réellement nécessaires ;
+- `( ) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
+- `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ;
+- `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- `( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
+- `( ) 0.1.7` — audits Python read-only d'un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.

- `(d) skeleton Tauri pour projets contrôlés` — la décision `0.0.5-alpha.9` conserve le candidat, mais sa matérialisation attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS et leur validation. Aucun numéro de release n'est réservé pour ce travail et `0.1.0` ne doit pas le considérer comme obligatoire par défaut.
+Le détail et les conditions de cette séquence sont conservés dans [`docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](docs/studies/003-V0_1_0_HORIZON_REVIEW.md).

-Cette entrée conserve une décision de report réelle ; elle ne transforme pas les autres candidats d'horizon en engagements. Les profils techniques supplémentaires, les projets documentaires/spécifications et l'audit de généricité hors logiciel restent chez leurs owners actuels tant qu'une revue d'horizon n'a pas décidé leur entrée dans la trajectoire engagée.
+## Trajectoires différées ou non numérotées

-Le plan de `0.1.0` devra programmer une revue d'horizon avant sa clôture, à un moment où la première baseline réutilisable sera assez établie pour juger la suite. Cette revue pourra se tenir dans une session stratégique séparée sans modifier `VERSION`. Elle décidera soit d'étendre la présente roadmap, soit de maintenir explicitement l'horizon ouvert avec un nouveau déclencheur de revue, soit de requalifier/différer/mettre en pause une trajectoire concernée.
+- `(d) skeleton Tauri avant owners Web suffisants` — la décision `0.0.5-alpha.9` reste vraie pendant `0.1.0`; `0.1.4` réexaminera cette décision après `0.1.1` et ne doit pas fabriquer un skeleton incomplet ;
+- `WASM` — candidat séparé à réévaluer pendant l'adoption Games si un owner PGR apporte une valeur immédiate ;
+- `serveur Web Rust / Actix Web ou alternative` — candidat à partir d'un corpus d'implémentation réel, pas sur la seule base d'une trajectoire roadmap ;
+- `saselang-bible`, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure `0.2.x` / `0.3.x` à décider ;
+- `deployment & operations` — famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon `0.4.x` ou `0.5.x` est plausible mais aucun numéro précis n'est réservé.
+
+Une nouvelle revue d'horizon doit intervenir si un prérequis réel invalide l'ordre engagé, notamment si `0.1.1` doit être scindée, si `0.1.4` ne peut pas lever le `DEFER` Tauri ou si Games exige un owner WASM/serveur avant une adoption proportionnée.

 Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`.
--- 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.0.5
+0.1.0
--- a/deltas/0.1.0/alpha.1.md
+++ b/deltas/0.1.0/alpha.1.md
@@ -0,0 +1,202 @@
+<!-- file: deltas/0.1.0/alpha.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable
+
+## Baseline et sources
+
+Baseline PGR autoritaire : `pgr-v0.0.5.zip`, archive source téléchargée depuis le tag Gitea `v0.0.5`, accompagnée du rapport externe `pgr-0.0.5-publish.001-report.md` avec statut `PASS`.
+
+SHA-256 vérifiés :
+
+```text
+pgr-v0.0.5.zip                        1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49
+pgr-0.0.5-publish.001-report.md       a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96
+games-v0.3.6.zip                      ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
+```
+
+Games et KSP sont uniquement des corpus de pression pour préparer l'adoption future ; ils ne sont ni modifiés ni incorporés à cette archive delta.
+
+Version avant application :
+
+```text
+0.0.5
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.1
+```
+
+## Objet
+
+Exécuter `prompts/006-V0_1_0_START_PROMPT.md` : auditer intégralement la stable `v0.0.5`, ses règles, profils, templates, skeletons, audits, décisions différées et chaîne de gouvernance, puis créer le plan de la première baseline réellement réutilisable avant tout changement normatif important.
+
+La tranche consigne également les décisions de cadrage acquises pendant la reprise :
+
+- corriger en `0.1.0` la convention future `rel.001` vers `rel.1` sans réécrire l'historique ;
+- distinguer le nom de tranche de fermeture du commit qui établit finalement la stable `X.Y.Z` ;
+- formaliser le handoff automatique des commandes Git après chaque history et des commandes/preuves de publication avant/après tag ;
+- traiter Web, serveur Rust/Actix, Java/Android, WASM et Tauri dans des releases `0.1.x` séparées, jamais comme un bloc unique `0.1.0` ;
+- préparer l'adoption de PGR par Games dès que son sous-ensemble requis est prêt, puis par KSP dont la pression est principalement Rust/Cargo + Tauri.
+
+Aucune de ces corrections n'est encore matérialisée normativement dans `alpha.1`.
+
+## Résultat de l'audit d'intake
+
+La stable et son rapport post-tag sont cohérents. L'archive contient `225` entrées sous `pgr/`, `194` fichiers et `31` répertoires, CRC propre, aucun symlink et aucune métadonnée `.git` attendue.
+
+La suite PGR donne `48/48` tests `PASS`. Les audits Markdown sont propres : `171` fichiers pour les headers, `8` tables sur `171` fichiers et `161` liens locaux sur `171` fichiers.
+
+Les `62` couples delta/history de `0.0.1` à `0.0.5` sont complets. Les `19` histories de `0.0.5` conservent leurs statuts réels, notamment `rel.001` `FAIL` puis `rel.001.fix.1` `PASS`.
+
+Les owners actuels couvrent déjà Rust/Cargo (`510`), Java/Maven/Gradle (`520`), Android (`610`) et Tauri (`710`). Les templates techniques actuels sont Rust/Cargo ; les skeletons concrets sont la fondation de gouvernance et le workspace Rust/Cargo. Le skeleton Tauri reste correctement `DEFER` tant que les owners Web manquants ne sont pas matérialisés.
+
+Games `0.3.6` confirme une pression réelle Web/Vite/TypeScript/Sass, Android/Gradle, Rust/WASM et Tauri, avec `0.3.7` réservé dans son propre roadmap à l'alignement PGR. KSP `0.3.16` contient six applications Tauri et un socle essentiellement Rust/Cargo. Ces observations servent au sizing futur et ne créent aucun profil dans cette tranche.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+```
+
+ADD :
+
+```text
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+deltas/0.1.0/alpha.1.md
+```
+
+DELETE : aucun.
+
+`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, les règles, profils, templates, skeletons, scripts et histories existants restent inchangés dans `alpha.1`.
+
+Aucun `history/0.1.0/alpha.1.md` n'est anticipé avant la gate opérateur.
+
+## Validation opérateur
+
+Après application sur la stable `0.0.5`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.1'
+test -f docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+test -f deltas/0.1.0/alpha.1.md
+test ! -e history/0.1.0/alpha.1.md
+
+grep -Fx '<!-- version: 15 -->' README.md
+grep -Fx '<!-- version: 18 -->' docs/000-README.md
+grep -F '006-V0_1_0_REUSABLE_BASELINE_PLAN.md' README.md docs/000-README.md
+
+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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+expected = {
+    '0.0.1': 12,
+    '0.0.2': 12,
+    '0.0.3': 10,
+    '0.0.4': 9,
+    '0.0.5': 19,
+}
+for release, count in expected.items():
+    deltas = {path.name for path in Path('deltas', release).glob('*.md')}
+    histories = {path.name for path in Path('history', release).glob('*.md')}
+    assert len(deltas) == count, (release, len(deltas))
+    assert deltas == histories, (release, sorted(deltas ^ histories))
+
+statuses = {}
+for path in Path('history/0.0.5').glob('*.md'):
+    text = path.read_text(encoding='utf-8')
+    match = re.search(r'## Statut\s+(PASS|FAIL|PARTIAL|BLOCKED)\s', text)
+    assert match is not None, path
+    statuses[path.name] = match.group(1)
+assert statuses['rel.001.md'] == 'FAIL'
+assert statuses['rel.001.fix.1.md'] == 'PASS'
+
+for path in (
+    Path('docs/rules/510-RUST_CARGO.md'),
+    Path('docs/rules/520-JAVA_MAVEN_GRADLE.md'),
+    Path('docs/rules/610-ANDROID.md'),
+    Path('docs/rules/710-TAURI.md'),
+    Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md'),
+    Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md'),
+    Path('docs/studies/002-TAURI_SKELETON_DECISION.md'),
+):
+    assert path.is_file(), path
+
+plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    'rel.1',
+    'première tranche qui obtient le PASS stable',
+    'Commandes opérateur et publication',
+    'une release/session par domaine cohérent',
+    'Games',
+    'KSP',
+    'TypeScript',
+    'Vite',
+    'Android',
+    'WASM',
+    'Tauri',
+    'Actix Web ou autre framework',
+    'beta.1 — réconciliation finale et revue d\'horizon',
+):
+    assert phrase in plan, phrase
+
+assert '- `( ) 0.1.0`' in Path('ROADMAP.md').read_text(encoding='utf-8')
+assert '- `( ) 0.1.1`' not in Path('ROADMAP.md').read_text(encoding='utf-8')
+print('0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered)')
+PY
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/alpha.1.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.0/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+La revue opérateur doit également confirmer que :
+
+- le plan ne transforme pas les futurs axes `0.1.x` en versions numérotées prématurément ;
+- Java/Android et Tauri sont reconnus comme profils existants, non recréés artificiellement ;
+- le `DEFER` du skeleton Tauri reste intact dans cette tranche ;
+- Games et KSP restent des corpus externes non modifiés ;
+- aucune règle Web/WASM/Actix n'est introduite dans `alpha.1` ;
+- les anciennes occurrences `rel.001*` restent intactes et historiques.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément le delta `0.1.0-alpha.2` consacré uniquement à la clôture stable `rel.N` et à l'identité du commit final.
+
+Après remise du history, fournir spontanément le bloc Git exact à exécuter pour fermer `alpha.1` avant application du delta suivant, même si la règle normative des handoffs automatiques ne sera matérialisée qu'en `alpha.3`.
+
+### FAIL
+
+Consigner le résultat réel dans le history, puis ouvrir `0.1.0-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement de `alpha.2` ne doit être absorbé silencieusement dans le fix.
--- a/deltas/0.1.0/alpha.2.fix.1.md
+++ b/deltas/0.1.0/alpha.2.fix.1.md
@@ -0,0 +1,178 @@
+<!-- file: deltas/0.1.0/alpha.2.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.2.fix.1 — correction de la gate `rel.N`
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.2`, réalisé après application de `history/0.1.0/alpha.2.md` avec statut `FAIL`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.2
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.2.fix.1
+```
+
+## Objet
+
+Corriger uniquement la gate opérateur défectueuse de `alpha.2`.
+
+Le contenu normatif de `docs/rules/200-GOVERNANCE.md` et `docs/rules/210-WORKFLOW.md` a déjà été couvert par la preuve Python de `alpha.2` et n'est pas modifié. Le défaut constaté provient de motifs `grep -F` entourés de quotes simples alors qu'ils contenaient des apostrophes littérales, notamment `n'utilise` et `l'exploitation`.
+
+Le delta historique `deltas/0.1.0/alpha.2.md` reste immuable.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/alpha.2.fix.1.md
+```
+
+DELETE : aucun.
+
+Aucun owner normatif, profil technologique, skeleton, template, script d'audit ou test n'est modifié par ce correctif.
+
+## Correction
+
+La validation du fix n'utilise plus de `grep` pour les phrases contenant apostrophes, backticks ou autres caractères shell sensibles. Ces assertions sont regroupées dans un bloc Python littéral sous heredoc quoté.
+
+Le fix vérifie à nouveau :
+
+- le history `alpha.2` en `FAIL` ;
+- la convention `rel.N` sans padding ;
+- la conservation des quatre artefacts historiques `rel.001*` de `0.0.5` ;
+- la distinction entre tranche de clôture et commit stable `X.Y.Z` ;
+- l'indépendance de `publish.001` ;
+- les horizons Clippy statique et deployment/operations différés ;
+- l'absence de réservation prématurée de `0.1.1` ;
+- les tests/audits globaux et le scope exact du fix.
+
+## Validation opérateur
+
+Après application du history `FAIL`, commit/push de `alpha.2`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.2.fix.1'
+git cat-file -e HEAD:history/0.1.0/alpha.2.md
+test -f history/0.1.0/alpha.2.md
+test -f deltas/0.1.0/alpha.2.md
+test -f deltas/0.1.0/alpha.2.fix.1.md
+test ! -e history/0.1.0/alpha.2.fix.1.md
+
+grep -A2 '^## Statut$' history/0.1.0/alpha.2.md | grep -Fx 'FAIL'
+grep -Fx '<!-- version: 5 -->' docs/rules/200-GOVERNANCE.md
+grep -Fx '<!-- version: 6 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 3 -->' 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.2.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+FAIL\s', history)
+
+governance = Path('docs/rules/200-GOVERNANCE.md').read_text(encoding='utf-8')
+workflow = Path('docs/rules/210-WORKFLOW.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')
+
+for phrase in (
+    'rel.1',
+    'rel.1.fix.1',
+    "représentation canonique n'utilise pas de zéro de padding",
+    'première tranche de clôture PASS',
+    'Le commit `X.Y.Z` MUST',
+):
+    assert phrase in governance or phrase in workflow, phrase
+
+for phrase in (
+    'history rel.1 FAIL / PARTIAL / BLOCKED',
+    'premier history rel.N[/fix.M] PASS qui établit réellement la stable',
+    'La présente règle ne renomme pas `publish.001`',
+):
+    assert phrase in workflow, phrase
+
+for phrase in (
+    'sous-ensemble des conventions Rust/Clippy',
+    "série dédiée au déploiement et à l'exploitation",
+    '### alpha.2.fix.1 — correction de la gate `rel.N`',
+):
+    assert phrase in plan, phrase
+
+for path in (
+    Path('deltas/0.0.5/rel.001.md'),
+    Path('history/0.0.5/rel.001.md'),
+    Path('deltas/0.0.5/rel.001.fix.1.md'),
+    Path('history/0.0.5/rel.001.fix.1.md'),
+):
+    assert path.is_file(), path
+
+assert 'publish.001' in workflow
+assert '- `( ) 0.1.1`' not in roadmap
+
+print('0.1.0 alpha.2.fix.1 rel gate audit: clean (failed gate preserved, rel.N content reconfirmed, shell-sensitive assertions safe)')
+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 docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/alpha.2.fix.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history du fix est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.2.fix.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le `FAIL` de `alpha.2` est conservé historiquement ;
+- `docs/rules/200-GOVERNANCE.md` et `docs/rules/210-WORKFLOW.md` ne sont pas modifiés par le fix ;
+- le delta historique `alpha.2.md` n'est pas réécrit ;
+- aucun élément du handoff automatique réservé à `alpha.3` n'est absorbé dans le correctif ;
+- aucun profil Web, Java/Android, WASM, Tauri ou serveur n'est ajouté ou modifié.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.2.fix.1.md`, l'appliquer puis committer/pousser le fix. Dans la même réponse, reprendre la trajectoire normale avec `0.1.0-alpha.3`, consacré au handoff automatique des commandes opérateur.
+
+Après remise du history, fournir spontanément le bloc Git exact permettant de fermer `alpha.2.fix.1` avant application de `alpha.3`.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.0/alpha.2.fix.1.md` et rester dans `alpha.2.fix.M`. Le scope MUST rester limité à la correction de la gate `rel.N` tant qu'aucun défaut plus large ne justifie un REPLAN.
--- a/deltas/0.1.0/alpha.2.md
+++ b/deltas/0.1.0/alpha.2.md
@@ -0,0 +1,201 @@
+<!-- file: deltas/0.1.0/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.2 — clôture stable et identité `rel.N`
+
+## Baseline
+
+Baseline attendue : `0.1.0-alpha.1` committée avec `history/0.1.0/alpha.1.md` en `PASS`.
+
+Cette tranche MUST être appliquée uniquement après le commit/push complet de `alpha.1` ; elle ne doit pas être superposée au workspace encore non committé de la gate précédente.
+
+Version avant application :
+
+```text
+0.1.0-alpha.1
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.2
+```
+
+## Objet
+
+Corriger la convention normative de clôture stable avant diffusion plus large de PGR :
+
+- utiliser `rel.1`, `rel.2`, etc. sans padding pour les nouvelles releases ;
+- conserver sans renommage tous les artefacts historiques `rel.001*` déjà publiés ;
+- distinguer le nom de la tranche de clôture de l'identité du commit stable ;
+- rendre explicite qu'une clôture `FAIL`, `PARTIAL` ou `BLOCKED` conserve le suffixe opérationnel dans son commit ;
+- rendre explicite que la première tranche `rel.N[/fix.M]` qui obtient réellement le `PASS` stable est committée sous `X.Y.Z` avant création du tag `vX.Y.Z`.
+
+La tranche ne modifie aucun profil technologique, skeleton, template, script d'audit ou convention de publication post-tag `publish.001`.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/rules/200-GOVERNANCE.md
+docs/rules/210-WORKFLOW.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/alpha.2.md
+```
+
+DELETE : aucun.
+
+Le plan actif est révisé parce qu'il enregistre `alpha.1 PASS` et deux horizons différés explicitement décidés pendant la session — audit Python d'un sous-ensemble Clippy après Games/KSP et future famille deployment/operations — sans leur attribuer de numéro ni les absorber dans `0.1.0`.
+
+Aucun `history/0.1.0/alpha.2.md` n'est anticipé avant la gate opérateur.
+
+## Convention obtenue
+
+La représentation future canonique est :
+
+```text
+rel.1
+rel.1.fix.1
+rel.2
+...
+```
+
+Pour le message du commit de clôture, le défaut PGR devient :
+
+```text
+history rel.1 FAIL / PARTIAL / BLOCKED
+    -> X.Y.Z-rel.1
+
+history rel.1.fix.1 FAIL / PARTIAL / BLOCKED
+    -> X.Y.Z-rel.1.fix.1
+
+premier history rel.N[/fix.M] PASS établissant réellement la stable
+    -> X.Y.Z
+```
+
+`VERSION` MAY déjà être `X.Y.Z` pendant ces tranches de fermeture : `rel.N` n'est pas une prerelease SemVer. Le tag `vX.Y.Z` intervient uniquement après le commit final `X.Y.Z` contenant le history `PASS` stable.
+
+Les fichiers historiques comme :
+
+```text
+deltas/0.0.5/rel.001.md
+history/0.0.5/rel.001.md
+deltas/0.0.5/rel.001.fix.1.md
+history/0.0.5/rel.001.fix.1.md
+```
+
+restent intacts.
+
+## Validation opérateur
+
+Après application sur le commit de `0.1.0-alpha.1`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.2'
+test -f history/0.1.0/alpha.1.md
+test -f deltas/0.1.0/alpha.2.md
+test ! -e history/0.1.0/alpha.2.md
+
+grep -Fx '<!-- version: 5 -->' docs/rules/200-GOVERNANCE.md
+grep -Fx '<!-- version: 6 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 2 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+
+grep -F 'représentation canonique n'utilise pas de zéro de padding' docs/rules/200-GOVERNANCE.md
+grep -F 'première tranche de clôture PASS' docs/rules/200-GOVERNANCE.md
+grep -F 'history rel.1 FAIL / PARTIAL / BLOCKED' docs/rules/210-WORKFLOW.md
+grep -F 'premier history rel.N[/fix.M] PASS qui établit réellement la stable' docs/rules/210-WORKFLOW.md
+grep -F 'La présente règle ne renomme pas `publish.001`' docs/rules/210-WORKFLOW.md
+
+grep -F 'sous-ensemble des conventions Rust/Clippy' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+grep -F 'série dédiée au déploiement et à l'exploitation' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+
+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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+history = Path('history/0.1.0/alpha.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', history)
+
+governance = Path('docs/rules/200-GOVERNANCE.md').read_text(encoding='utf-8')
+workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
+plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
+
+for phrase in (
+    'rel.1',
+    'rel.1.fix.1',
+    'représentation canonique n\'utilise pas de zéro de padding',
+    'première tranche de clôture PASS',
+    'Le commit `X.Y.Z` MUST',
+):
+    assert phrase in governance or phrase in workflow, phrase
+
+for path in (
+    Path('deltas/0.0.5/rel.001.md'),
+    Path('history/0.0.5/rel.001.md'),
+    Path('deltas/0.0.5/rel.001.fix.1.md'),
+    Path('history/0.0.5/rel.001.fix.1.md'),
+):
+    assert path.is_file(), path
+
+assert 'publish.001' in workflow
+assert 'La présente règle ne renomme pas `publish.001`' in workflow
+assert 'sous-ensemble des conventions Rust/Clippy' in plan
+assert "série dédiée au déploiement et à l'exploitation" in plan
+assert '- `( ) 0.1.1`' not in Path('ROADMAP.md').read_text(encoding='utf-8')
+
+print('0.1.0 alpha.2 rel identity audit: clean (rel.N unpadded, historical rel.001 preserved, stable commit identity explicit)')
+PY
+
+git diff --check
+git add VERSION docs/rules/200-GOVERNANCE.md docs/rules/210-WORKFLOW.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/alpha.2.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.2.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/rules/200-GOVERNANCE.md
+M  docs/rules/210-WORKFLOW.md
+```
+
+La revue opérateur doit également confirmer que :
+
+- aucune occurrence historique `rel.001*` n'a été renommée ;
+- `publish.001` reste une convention indépendante et n'est pas modifiée par cette tranche ;
+- aucune commande de handoff Git automatique n'est encore rendue normative ici — ce sujet appartient à `alpha.3` ;
+- les horizons Clippy statique et deployment/operations restent de simples candidats différés dans le plan ;
+- aucun profil Web, Java/Android, WASM, Tauri ou serveur n'est ajouté ou modifié.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.2.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément `0.1.0-alpha.3` consacré au handoff automatique des commandes opérateur après history, au commit/push, au tag stable et aux preuves requises pour `publish.001`.
+
+Après remise du history, fournir déjà spontanément le bloc Git exact de fermeture de `alpha.2`, conformément à la décision acquise, même si `alpha.3` sera la tranche qui rendra ce comportement normatif.
+
+### FAIL
+
+Consigner le résultat réel dans le history puis ouvrir `0.1.0-alpha.2.fix.1` ou un REPLAN selon la cause. Aucun élément du handoff automatique prévu pour `alpha.3` ne doit être absorbé silencieusement dans le fix.
--- a/deltas/0.1.0/alpha.3.fix.1.md
+++ b/deltas/0.1.0/alpha.3.fix.1.md
@@ -0,0 +1,167 @@
+<!-- file: deltas/0.1.0/alpha.3.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.3.fix.1 — correction de la gate du handoff opérateur
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.3`, réalisé après application de `history/0.1.0/alpha.3.md` avec statut `FAIL`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.3
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.3.fix.1
+```
+
+## Objet
+
+Corriger uniquement la syntaxe défectueuse de la gate opérateur de `alpha.3`.
+
+Le contenu normatif de `docs/rules/210-WORKFLOW.md`, le pattern `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`, l'index `docs/000-README.md` et le delta historique `deltas/0.1.0/alpha.3.md` restent inchangés.
+
+Le défaut observé était un littéral Python entouré de quotes simples alors que son texte contenait l'apostrophe de `d'une` :
+
+```python
+'## Fermeture d'une tranche non stable'
+```
+
+Le fix rend les assertions textuelles syntaxiquement sûres sans modifier ce qu'elles vérifient.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/alpha.3.fix.1.md
+```
+
+DELETE : aucun.
+
+Aucun owner normatif, template, profil technologique, skeleton, script d'audit ou test n'est modifié par ce correctif.
+
+## Validation opérateur
+
+Après application du history `FAIL`, commit/push de `alpha.3`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.3.fix.1'
+git cat-file -e HEAD:history/0.1.0/alpha.3.md
+test -f history/0.1.0/alpha.3.md
+test -f deltas/0.1.0/alpha.3.md
+test -f deltas/0.1.0/alpha.3.fix.1.md
+test -f docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+test ! -e history/0.1.0/alpha.3.fix.1.md
+
+grep -A2 '^## Statut$' history/0.1.0/alpha.3.md | grep -Fx 'FAIL'
+grep -Fx '<!-- version: 7 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 1 -->' docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+grep -Fx '<!-- version: 19 -->' docs/000-README.md
+grep -Fx '<!-- version: 5 -->' 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.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+FAIL\s', history)
+
+workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
+template = Path('docs/templates/006-OPERATOR_COMMAND_HANDOFF.md').read_text(encoding='utf-8')
+plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+
+workflow_phrases = (
+    '## Remise automatique des commandes opérateur',
+    'le générateur MUST remettre spontanément les commandes nécessaires pour fermer cette tranche',
+    'Le générateur MUST NOT inventer un remote, une branche ou une politique de tag non établis.',
+    'première clôture `rel.N[/fix.M]` qui établit réellement la stable',
+    'refs/tags/vX.Y.Z^{}',
+    'Le rapport `publish.*` est produit seulement à partir des artefacts et preuves réellement disponibles après publication.',
+    '../templates/006-OPERATOR_COMMAND_HANDOFF.md',
+)
+for phrase in workflow_phrases:
+    assert phrase in workflow, phrase
+
+template_phrases = (
+    "## Fermeture d'une tranche non stable",
+    'git diff --cached --check',
+    'git push <remote> <branche>',
+    "## Tranche échouée suivie d'un fix",
+    '## Première clôture qui établit réellement la stable',
+    'git tag -a vX.Y.Z -m "vX.Y.Z"',
+    "git ls-remote <remote> 'refs/tags/vX.Y.Z^{}'",
+    '## Remise nécessaire pour `publish.*`',
+    '## Après `publish.* PASS`',
+)
+for phrase in template_phrases:
+    assert phrase in template, phrase
+
+assert '006-OPERATOR_COMMAND_HANDOFF.md' in index
+assert 'Statut opérateur : **FAIL**.' in plan
+assert '### alpha.3.fix.1 — correction de la gate du handoff opérateur' in plan
+
+print('0.1.0 alpha.3.fix.1 operator handoff gate: clean (alpha.3 FAIL preserved, workflow/template reconfirmed, Python literals safe)')
+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 docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/alpha.3.fix.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history du fix est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.3.fix.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le `FAIL` de `alpha.3` est conservé historiquement ;
+- `docs/rules/210-WORKFLOW.md`, `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md` et `docs/000-README.md` ne sont pas modifiés par le fix ;
+- le delta historique `alpha.3.md` n'est pas réécrit ;
+- aucun contenu prévu pour `alpha.4` n'est absorbé dans le correctif ;
+- aucun profil technologique n'est ajouté ou modifié.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.3.fix.1.md`, l'appliquer puis committer/pousser le fix. Reprendre ensuite la trajectoire normale avec `0.1.0-alpha.4`, consacré à l'adoption proportionnée de PGR par un projet existant.
+
+Le handoff remis après ce PASS doit lui-même suivre le contrat `210-WORKFLOW` et `006-OPERATOR_COMMAND_HANDOFF.md` désormais reconfirmé.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.0/alpha.3.fix.1.md` et rester dans `alpha.3.fix.M`. Le scope MUST rester limité à la correction de la gate du handoff tant qu'aucun défaut plus large ne justifie un REPLAN.
--- a/deltas/0.1.0/alpha.3.md
+++ b/deltas/0.1.0/alpha.3.md
@@ -0,0 +1,185 @@
+<!-- file: deltas/0.1.0/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.3 — handoff automatique des commandes opérateur
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.2.fix.1`, réalisé après application de `history/0.1.0/alpha.2.fix.1.md` avec statut `PASS`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.2.fix.1
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.3
+```
+
+## Objet
+
+Rendre normative la remise automatique des commandes opérateur après chaque history et pendant la publication stable.
+
+La tranche doit supprimer le besoin récurrent de demander séparément :
+
+```text
+quel message de commit utiliser ?
+quand pousser ?
+quand appliquer le prochain delta ?
+quelles commandes exécuter pour le tag ?
+quelles preuves fournir pour produire publish.* ?
+```
+
+Le workflow reste l'owner normatif. Un nouveau pattern documentaire fournit uniquement une forme de rendu réutilisable.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/000-README.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+docs/rules/210-WORKFLOW.md
+```
+
+ADD :
+
+```text
+docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+deltas/0.1.0/alpha.3.md
+```
+
+DELETE : aucun.
+
+## Changements normatifs
+
+`210-WORKFLOW.md` impose désormais qu'après production d'un history destiné à l'opérateur, le générateur fournisse spontanément le bloc de fermeture correspondant. Le rendu doit utiliser les valeurs Git réelles lorsqu'elles sont établies et ne doit jamais inventer branche, remote ou politique de tag.
+
+Le contrat distingue explicitement :
+
+- fermeture ordinaire `history -> commit/push -> delta suivant` ;
+- fermeture `FAIL/PARTIAL/BLOCKED -> commit de la tranche -> fix` ;
+- première clôture `rel.N[/fix.M] PASS -> commit X.Y.Z -> tag` ;
+- vérification d'un tag annoté avec distinction objet tag / commit déréférencé ;
+- artefacts et preuves que l'opérateur doit fournir pour produire `publish.*` ;
+- message manuel de reprise après `publish.* PASS` déjà possédé par `003-NEW_SESSION_PROMPT.md`.
+
+## Nouveau pattern documentaire
+
+`docs/templates/006-OPERATOR_COMMAND_HANDOFF.md` fournit les blocs adaptables pour :
+
+```text
+history ZIP
+commit / push
+fix ou delta suivant
+tag stable
+preuves post-tag
+transition après publish.*
+```
+
+Il ne fixe pas `origin`, `master` ou une forge particulière comme valeurs universelles. Une commande concrète livrée à l'opérateur doit employer les valeurs déjà établies pour le projet.
+
+## Validation opérateur
+
+Exécuter depuis la racine du workspace après application du delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.3'
+test -f history/0.1.0/alpha.2.fix.1.md
+test -f deltas/0.1.0/alpha.3.md
+test -f docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+test ! -e history/0.1.0/alpha.3.md
+
+grep -Fx '<!-- version: 7 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 19 -->' docs/000-README.md
+grep -Fx '<!-- version: 4 -->' 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.2.fix.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', history)
+
+workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
+template = Path('docs/templates/006-OPERATOR_COMMAND_HANDOFF.md').read_text(encoding='utf-8')
+plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+
+for phrase in (
+    '## Remise automatique des commandes opérateur',
+    "le générateur MUST remettre spontanément les commandes nécessaires pour fermer cette tranche",
+    'Le générateur MUST NOT inventer un remote, une branche ou une politique de tag non établis.',
+    'première clôture `rel.N[/fix.M]` qui établit réellement la stable',
+    'refs/tags/vX.Y.Z^{}',
+    'Le rapport `publish.*` est produit seulement à partir des artefacts et preuves réellement disponibles après publication.',
+    '../templates/006-OPERATOR_COMMAND_HANDOFF.md',
+):
+    assert phrase in workflow, phrase
+
+for phrase in (
+    '## Fermeture d'une tranche non stable',
+    'git diff --cached --check',
+    'git push <remote> <branche>',
+    '## Tranche échouée suivie d'un fix',
+    '## Première clôture qui établit réellement la stable',
+    'git tag -a vX.Y.Z -m "vX.Y.Z"',
+    "git ls-remote <remote> 'refs/tags/vX.Y.Z^{}'",
+    '## Remise nécessaire pour `publish.*`',
+    '## Après `publish.* PASS`',
+):
+    assert phrase in template, phrase
+
+assert '006-OPERATOR_COMMAND_HANDOFF.md' in index
+assert 'Statut opérateur : **PASS**.' in plan
+assert '### alpha.3 — handoff automatique des commandes opérateur' in plan
+
+print('0.1.0 alpha.3 operator handoff audit: clean (history-to-commit, stable tag and publish evidence rendered explicitly)')
+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 docs/000-README.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    docs/rules/210-WORKFLOW.md \
+    docs/templates/006-OPERATOR_COMMAND_HANDOFF.md \
+    deltas/0.1.0/alpha.3.md
+git diff --cached --check
+git status --short
+```
+
+## Résultat attendu
+
+La gate est `PASS` si :
+
+- le history `alpha.2.fix.1` est présent et `PASS` ;
+- le workflow impose la remise spontanée des commandes et interdit d'inventer les paramètres Git ;
+- le pattern couvre tranche ordinaire, échec + fix, stable/tag et preuves `publish.*` ;
+- la vérification d'un tag annoté distingue objet tag et commit déréférencé ;
+- les `48` tests existants restent propres ;
+- les trois audits Markdown restent propres ;
+- le scope Git correspond exactement aux six fichiers de `alpha.3`.
+
+## Transition
+
+Si `PASS` :
+
+1. produire `history/0.1.0/alpha.3.md` ;
+2. remettre automatiquement le bloc opérateur conforme au nouveau pattern pour committer/pousser `0.1.0-alpha.3` ;
+3. préparer `0.1.0-alpha.4`, consacré à l'adoption proportionnée de PGR par un projet existant.
+
+Si `FAIL` : conserver le history réel et corriger uniquement la cause dans `alpha.3.fix.N`, sauf preuve imposant un REPLAN.
--- 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/deltas/0.1.0/alpha.5.md
+++ b/deltas/0.1.0/alpha.5.md
@@ -0,0 +1,371 @@
+<!-- file: deltas/0.1.0/alpha.5.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-alpha.5 — baseline Rust/Cargo réutilisable et dry-run
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.4`, réalisé après application de `history/0.1.0/alpha.4.md` avec statut `PASS`.
+
+Le hash de ce commit n’est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.4
+```
+
+Version après application :
+
+```text
+0.1.0-alpha.5
+```
+
+## Objet
+
+Prouver que la première baseline Rust/Cargo de PGR est réellement réutilisable dans deux situations distinctes :
+
+```text
+NEW       nouveau workspace gouverné depuis une baseline vide
+ADOPTION  workspace Rust existant conservant ses décisions locales légitimes
+```
+
+La tranche réconcilie les skeletons `001` / `002`, les guides des templates Rust/Cargo et la validation. Elle ajoute un contrat durable de dry-run, mais aucun générateur de projet permanent et aucun nouveau profil technologique.
+
+Games et KSP ne servent pas de fixtures et ne sont pas modifiés.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/000-README.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+docs/skeletons/000-README.md
+docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+docs/templates/001-RUST_CARGO_TOOLING.md
+docs/templates/002-CARGO_MANIFESTS.md
+docs/validation/001-VALIDATION_MATRIX.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/alpha.5.md
+docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+```
+
+DELETE : aucun.
+
+Les templates techniques sous `templates/rust-cargo/`, les scripts d’audit, les profils Java/Android/Tauri, `ROADMAP.md` et `CHANGELOG.md` restent inchangés.
+
+## Décisions
+
+### Nouveau projet
+
+Le chemin d’instanciation reste `001 + 002`. Les cinq templates techniques sont adaptés dans un répertoire temporaire, les placeholders sont résolus et une crate source triviale est créée uniquement pour permettre à Cargo de vérifier la baseline.
+
+Le code temporaire du dry-run n’est pas ajouté aux templates PGR.
+
+### Projet existant
+
+Le chemin d’adoption passe par `230-ADOPTION.md`. Les skeletons et templates servent de checklists de comparaison et ne sont jamais copiés aveuglément.
+
+Le dry-run doit inclure plusieurs décisions et prouver qu’un choix local classé `KEEP-LOCAL` ou `DEFER` reste inchangé.
+
+### Autorité de la toolchain
+
+La syntaxe TOML et les assertions structurelles peuvent être prévalidées avec Python. En revanche, le mode `NEW` complet exige Cargo : une absence de toolchain ne peut pas être convertie en `PASS`.
+
+## Validation opérateur
+
+Après application du history `PASS`, commit/push de `alpha.4`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-alpha.5'
+git cat-file -e HEAD:history/0.1.0/alpha.4.md
+test -f history/0.1.0/alpha.4.md
+test -f deltas/0.1.0/alpha.5.md
+test -f docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+test ! -e history/0.1.0/alpha.5.md
+
+grep -A2 '^## Statut$' history/0.1.0/alpha.4.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 21 -->' docs/000-README.md
+grep -Fx '<!-- version: 5 -->' docs/skeletons/000-README.md
+grep -Fx '<!-- version: 4 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+grep -Fx '<!-- version: 6 -->' docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+grep -Fx '<!-- version: 4 -->' docs/templates/001-RUST_CARGO_TOOLING.md
+grep -Fx '<!-- version: 4 -->' docs/templates/002-CARGO_MANIFESTS.md
+grep -Fx '<!-- version: 13 -->' docs/validation/001-VALIDATION_MATRIX.md
+grep -Fx '<!-- version: 1 -->' docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+grep -Fx '<!-- version: 7 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Contrôle structurel et prévalidation TOML :
+
+```bash
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+import tomllib
+
+history = Path("history/0.1.0/alpha.4.md").read_text(encoding="utf-8")
+foundation = Path("docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md").read_text(encoding="utf-8")
+rust_skeleton = Path("docs/skeletons/002-RUST_CARGO_WORKSPACE.md").read_text(encoding="utf-8")
+tooling = Path("docs/templates/001-RUST_CARGO_TOOLING.md").read_text(encoding="utf-8")
+manifests = Path("docs/templates/002-CARGO_MANIFESTS.md").read_text(encoding="utf-8")
+dryrun = Path("docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.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)
+assert "../rules/230-ADOPTION.md" in foundation
+assert "../rules/230-ADOPTION.md" in rust_skeleton
+assert "004-RUST_CARGO_BASELINE_DRY_RUN.md" in rust_skeleton
+assert "KEEP-LOCAL" in tooling
+assert "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER" in manifests
+
+for phrase in (
+    "NEW       nouveau projet",
+    "ADOPTION  projet existant",
+    "cargo metadata --format-version 1 --no-deps",
+    "cargo clippy --workspace --all-targets --all-features -- -D warnings",
+    "KEEP-LOCAL",
+    "DEFER",
+    "ne constitue pas un `PASS` de la toolchain",
+):
+    assert phrase in dryrun, phrase
+
+for path in (
+    Path("templates/rust-cargo/Cargo.toml"),
+    Path("templates/rust-cargo/clippy.toml"),
+    Path("templates/rust-cargo/rustfmt.toml"),
+    Path("templates/rust-cargo/.cargo/config.toml"),
+    Path("templates/rust-cargo/crates/project-core-lib/Cargo.toml"),
+):
+    with path.open("rb") as handle:
+        tomllib.load(handle)
+
+assert "Statut opérateur : **PASS**." in plan
+assert "Statut opérateur : **à valider**." in plan
+assert "Games et KSP ne sont pas utilisés comme fixtures du dry-run." in plan
+assert "- `( ) 0.1.1`" not in roadmap
+
+print("0.1.0 alpha.5 structural/TOML audit: clean (NEW and ADOPTION paths explicit, templates parse, external corpora not required)")
+PYGATE
+```
+
+Dry-run `NEW` avec la toolchain officielle :
+
+```bash
+python3 -B - <<'PYNEW'
+from pathlib import Path
+import shutil
+import subprocess
+import tempfile
+import tomllib
+
+cargo = shutil.which("cargo")
+if cargo is None:
+    raise SystemExit("BLOCKED: cargo is required for the alpha.5 NEW dry-run")
+
+source = Path("templates/rust-cargo")
+with tempfile.TemporaryDirectory(prefix="pgr-alpha5-new-") as temporary:
+    root = Path(temporary)
+    (root / ".cargo").mkdir(parents=True)
+    (root / "crates/pgr-dryrun-core-lib/src").mkdir(parents=True)
+
+    shutil.copy2(source / "Cargo.toml", root / "Cargo.toml")
+    shutil.copy2(source / "clippy.toml", root / "clippy.toml")
+    shutil.copy2(source / "rustfmt.toml", root / "rustfmt.toml")
+    shutil.copy2(source / ".cargo/config.toml", root / ".cargo/config.toml")
+    shutil.copy2(source / "crates/project-core-lib/Cargo.toml", root / "crates/pgr-dryrun-core-lib/Cargo.toml")
+
+    workspace = (root / "Cargo.toml").read_text(encoding="utf-8")
+    workspace = workspace.replace("crates/project-core-lib", "crates/pgr-dryrun-core-lib")
+    workspace = workspace.replace('version = "0.1.0"', 'version = "9.9.9"')
+    (root / "Cargo.toml").write_text(workspace, encoding="utf-8")
+
+    member = (root / "crates/pgr-dryrun-core-lib/Cargo.toml").read_text(encoding="utf-8")
+    member = member.replace("project-core-lib", "pgr-dryrun-core-lib")
+    (root / "crates/pgr-dryrun-core-lib/Cargo.toml").write_text(member, encoding="utf-8")
+
+    config = (root / ".cargo/config.toml").read_text(encoding="utf-8")
+    config = config.replace("project-name", "pgr-alpha5-new")
+    (root / ".cargo/config.toml").write_text(config, encoding="utf-8")
+
+    (root / "crates/pgr-dryrun-core-lib/src/lib.rs").write_text(
+        "//! Minimal source used only by the PGR alpha.5 dry-run.\n\n"
+        "/// Returns the dry-run marker.\n"
+        "#[must_use]\n"
+        "pub const fn dry_run_marker() -> u32 {\n"
+        "    return 1;\n"
+        "}\n",
+        encoding="utf-8",
+    )
+
+    for path in (
+        root / "Cargo.toml",
+        root / "clippy.toml",
+        root / "rustfmt.toml",
+        root / ".cargo/config.toml",
+        root / "crates/pgr-dryrun-core-lib/Cargo.toml",
+    ):
+        with path.open("rb") as handle:
+            tomllib.load(handle)
+        text = path.read_text(encoding="utf-8")
+        assert "project-name" not in text
+        assert "project-core-lib" not in text
+
+    commands = (
+        [cargo, "metadata", "--format-version", "1", "--no-deps"],
+        [cargo, "fmt", "--all", "--", "--check"],
+        [cargo, "check", "--workspace"],
+        [cargo, "clippy", "--workspace", "--all-targets", "--all-features", "--", "-D", "warnings"],
+    )
+    for command in commands:
+        subprocess.run(command, cwd=root, check=True)
+
+print("0.1.0 alpha.5 NEW dry-run: clean (temporary templates accepted by Cargo/rustfmt/Clippy)")
+PYNEW
+```
+
+Dry-run `ADOPTION` non destructif :
+
+```bash
+python3 -B - <<'PYADOPT'
+from pathlib import Path
+import hashlib
+import shutil
+import subprocess
+import tempfile
+
+cargo = shutil.which("cargo")
+if cargo is None:
+    raise SystemExit("BLOCKED: cargo is required for the alpha.5 ADOPTION dry-run")
+
+valid_decisions = {"ADOPT", "KEEP-LOCAL", "OVERRIDE", "DEFER"}
+with tempfile.TemporaryDirectory(prefix="pgr-alpha5-adoption-") as temporary:
+    root = Path(temporary)
+    (root / "crates/legacy-core-lib/src").mkdir(parents=True)
+
+    (root / "Cargo.toml").write_text(
+        '[workspace]\nresolver = "3"\nmembers = ["crates/legacy-core-lib"]\n\n'
+        '[workspace.package]\nversion = "2.3.4"\nedition = "2024"\npublish = false\n',
+        encoding="utf-8",
+    )
+    (root / "rustfmt.toml").write_text('edition = "2024"\nmax_width = 120\n', encoding="utf-8")
+    (root / "crates/legacy-core-lib/Cargo.toml").write_text(
+        '[package]\nname = "legacy-core-lib"\nversion.workspace = true\nedition.workspace = true\npublish.workspace = true\n',
+        encoding="utf-8",
+    )
+    (root / "crates/legacy-core-lib/src/lib.rs").write_text(
+        "//! Existing synthetic library.\n\n"
+        "/// Returns the existing marker.\n"
+        "#[must_use]\n"
+        "pub const fn existing_marker() -> u32 {\n"
+        "    7\n"
+        "}\n",
+        encoding="utf-8",
+    )
+
+    protected = (root / "Cargo.toml", root / "rustfmt.toml", root / "crates/legacy-core-lib/Cargo.toml")
+    before = {path: hashlib.sha256(path.read_bytes()).hexdigest() for path in protected}
+
+    decisions = {
+        "510-RUST_CARGO": "ADOPT",
+        "rustfmt.max_width=120": "KEEP-LOCAL",
+        "PGR external artifact configuration": "DEFER",
+        "strict crate-root export audit": "DEFER",
+    }
+    assert set(decisions.values()) <= valid_decisions
+    assert "KEEP-LOCAL" in decisions.values()
+    assert "DEFER" in decisions.values()
+
+    for command in (
+        [cargo, "metadata", "--format-version", "1", "--no-deps"],
+        [cargo, "fmt", "--all", "--", "--check"],
+        [cargo, "check", "--workspace"],
+        [cargo, "clippy", "--workspace", "--all-targets", "--all-features", "--", "-D", "warnings"],
+    ):
+        subprocess.run(command, cwd=root, check=True)
+
+    after = {path: hashlib.sha256(path.read_bytes()).hexdigest() for path in protected}
+    assert before == after
+    assert "max_width = 120" in (root / "rustfmt.toml").read_text(encoding="utf-8")
+    assert not (root / ".cargo/config.toml").exists()
+
+print("0.1.0 alpha.5 ADOPTION dry-run: clean (local KEEP-LOCAL/DEFER choices preserved, workspace remains valid)")
+PYADOPT
+```
+
+Puis rejouer les preuves PGR :
+
+```bash
+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 docs/000-README.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    docs/skeletons/000-README.md \
+    docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
+    docs/skeletons/002-RUST_CARGO_WORKSPACE.md \
+    docs/templates/001-RUST_CARGO_TOOLING.md \
+    docs/templates/002-CARGO_MANIFESTS.md \
+    docs/validation/001-VALIDATION_MATRIX.md \
+    docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md \
+    deltas/0.1.0/alpha.5.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history de `alpha.5` est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.5.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/skeletons/000-README.md
+M  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+M  docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+M  docs/templates/001-RUST_CARGO_TOOLING.md
+M  docs/templates/002-CARGO_MANIFESTS.md
+M  docs/validation/001-VALIDATION_MATRIX.md
+A  docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le mode `NEW` n’introduit aucun `src/lib.rs` universel dans PGR ;
+- le mode `ADOPTION` ne remplace pas les fichiers existants classés `KEEP-LOCAL` ou `DEFER` ;
+- les templates techniques eux-mêmes restent inchangés dans cette tranche ;
+- la réussite de la prévalidation Python n’est pas confondue avec la réussite Cargo ;
+- Games et KSP ne sont ni modifiés ni nécessaires à la preuve ;
+- aucun profil Java, Android, Tauri, Web, WASM ou serveur n’est matérialisé ;
+- aucun numéro futur `0.1.x` n’est réservé.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.0/alpha.5.md`, l’appliquer puis remettre automatiquement les commandes de commit/push.
+
+Passer ensuite à `0.1.0-beta.1` pour la réconciliation finale et la revue d’horizon obligatoire avant RC.
+
+### FAIL / BLOCKED
+
+Consigner le résultat réel dans `history/0.1.0/alpha.5.md`. Un défaut des templates/skeletons reste dans `alpha.5.fix.N` sauf REPLAN. Une toolchain Cargo absente qui empêche les dry-runs requis doit être enregistrée `BLOCKED`, pas transformée en `PASS` par la seule prévalidation Python.
--- a/deltas/0.1.0/beta.1.md
+++ b/deltas/0.1.0/beta.1.md
@@ -0,0 +1,237 @@
+<!-- file: deltas/0.1.0/beta.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-beta.1 — réconciliation finale et revue d'horizon
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-alpha.5`, réalisé après application de `history/0.1.0/alpha.5.md` avec statut `PASS`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-alpha.5
+```
+
+Version après application :
+
+```text
+0.1.0-beta.1
+```
+
+## Objet
+
+Fermer la phase alpha de `0.1.0` en réconciliant la baseline réellement validée et en exécutant la revue d'horizon obligatoire avant RC.
+
+La tranche :
+
+- enregistre le `PASS` de `alpha.5` dans le plan actif ;
+- matérialise `003-V0_1_0_HORIZON_REVIEW.md` ;
+- engage dans `ROADMAP.md` uniquement les prochaines releases `0.1.x` suffisamment décidées ;
+- conserve WASM, serveur Rust et deployment/operations sans réservation prématurée ;
+- prépare `007-V0_1_1_START_PROMPT.md` pour la prochaine cible Web, sans l'activer avant publication de `v0.1.0`.
+
+Aucun profil technique, template Rust/Cargo, skeleton ou script d'audit n'est modifié dans `beta.1`.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+ROADMAP.md
+docs/000-README.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+docs/studies/000-README.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/beta.1.md
+docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+prompts/007-V0_1_1_START_PROMPT.md
+```
+
+DELETE : aucun.
+
+`README.md`, `RULES.md`, `CHANGELOG.md`, les profils, skeletons, templates techniques et scripts restent inchangés.
+
+## Décision de revue d'horizon
+
+Les releases suivantes sont engagées :
+
+```text
+0.1.1  fondation frontend Web
+0.1.2  réévaluation Java / Gradle
+0.1.3  réévaluation Android
+0.1.4  domaine Tauri et levée conditionnelle du DEFER
+0.1.5  adoption Games
+0.1.6  adoption KSP
+0.1.7  audits Rust/Clippy statiques Python-only
+```
+
+Cette séquence applique le principe « une release/session par domaine cohérent » et conserve Games avant KSP.
+
+`0.1.4` n'autorise pas par avance le skeleton Tauri : la release doit d'abord vérifier que `0.1.1` a réellement fourni les owners Web nécessaires.
+
+WASM et serveur Rust/Actix ou alternative restent non numérotés. Le futur domaine deployment/operations reste un horizon majeur possible, notamment `0.4.x` ou `0.5.x`, sans réservation précise.
+
+## Prochaine cible
+
+Après stable `v0.1.0` et `publish.* PASS`, la prochaine cible engagée est :
+
+```text
+0.1.1 — fondation frontend Web
+```
+
+Le prompt `prompts/007-V0_1_1_START_PROMPT.md` demande un audit indépendant de la stable et du corpus Games réellement fourni. Il ne migre pas Games et ne crée ni Tauri, ni WASM, ni serveur Rust.
+
+## Validation opérateur
+
+Après application du history `PASS`, commit/push de `alpha.5`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-beta.1'
+git cat-file -e HEAD:history/0.1.0/alpha.5.md
+test -f history/0.1.0/alpha.5.md
+test -f deltas/0.1.0/beta.1.md
+test -f docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+test -f prompts/007-V0_1_1_START_PROMPT.md
+test ! -e history/0.1.0/beta.1.md
+
+grep -A2 '^## Statut$' history/0.1.0/alpha.5.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 9 -->' ROADMAP.md
+grep -Fx '<!-- version: 22 -->' docs/000-README.md
+grep -Fx '<!-- version: 8 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+grep -Fx '<!-- version: 3 -->' docs/studies/000-README.md
+grep -Fx '<!-- version: 1 -->' docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+grep -Fx '<!-- version: 1 -->' prompts/007-V0_1_1_START_PROMPT.md
+```
+
+Contrôle structurel de la revue :
+
+```bash
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+history = Path("history/0.1.0/alpha.5.md").read_text(encoding="utf-8")
+roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
+plan = Path("docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md").read_text(encoding="utf-8")
+study = Path("docs/studies/003-V0_1_0_HORIZON_REVIEW.md").read_text(encoding="utf-8")
+prompt = Path("prompts/007-V0_1_1_START_PROMPT.md").read_text(encoding="utf-8")
+tauri = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
+
+assert re.search(r"## Statut\s+PASS\s", history)
+
+expected = {
+    "0.1.1": "fondation frontend Web",
+    "0.1.2": "Java/Maven/Gradle",
+    "0.1.3": "Android",
+    "0.1.4": "Tauri",
+    "0.1.5": "sasedev-games",
+    "0.1.6": "khadhroony-solana-project",
+    "0.1.7": "Rust/Clippy",
+}
+for version, phrase in expected.items():
+    assert f"- `( ) {version}`" in roadmap, version
+    assert phrase in roadmap, phrase
+
+assert "- `( ) 0.1.8`" not in roadmap
+assert "WASM" in roadmap
+assert "serveur Web Rust / Actix Web ou alternative" in roadmap
+assert "deployment & operations" in roadmap
+assert "aucun numéro précis n'est réservé" in roadmap
+
+for phrase in (
+    "`0.1.1` — fondation frontend Web",
+    "`0.1.5` — adoption de Games",
+    "`0.1.6` — adoption de KSP",
+    "`0.1.7` — audits Rust/Clippy statiques Python",
+    "Candidats laissés sans numéro",
+    "Déploiement et exploitation",
+    "La décision `DEFER` de `002-TAURI_SKELETON_DECISION.md` reste vraie pendant `0.1.0`.",
+):
+    assert phrase in study, phrase
+
+assert "Statut opérateur : **PASS**." in plan
+assert "Statut opérateur : **à valider**." in plan
+assert "0.1.7  audits Rust/Clippy statiques Python-only" in plan
+assert "WASM, serveur Rust et deployment restent non numérotés." in plan
+
+for phrase in (
+    "# Prompt de démarrage 0.1.1 — fondation frontend Web",
+    "games-v0.3.6.zip",
+    "TypeScript",
+    "Vite",
+    "Sass/CSS",
+    "Le skeleton Tauri reste `DEFER` pendant cette release.",
+    "0.1.2",
+    "0.1.3",
+):
+    assert phrase in prompt, phrase
+
+assert "DEFER" in tauri
+print("0.1.0 beta.1 horizon review audit: clean (0.1.1..0.1.7 engaged, Tauri conditional, deferred domains remain unnumbered)")
+PYGATE
+```
+
+Puis rejouer les preuves PGR :
+
+```bash
+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 ROADMAP.md docs/000-README.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    docs/studies/000-README.md \
+    docs/studies/003-V0_1_0_HORIZON_REVIEW.md \
+    prompts/007-V0_1_1_START_PROMPT.md \
+    deltas/0.1.0/beta.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history de `beta.1` est exactement :
+
+```text
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.0/beta.1.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+A  prompts/007-V0_1_1_START_PROMPT.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- la roadmap n'engage pas un catalogue exhaustif de technologies ;
+- chaque release `0.1.1` à `0.1.7` possède un domaine cohérent ;
+- Games reste avant KSP ;
+- le skeleton Tauri n'est pas présenté comme déjà autorisé ;
+- WASM et serveur Rust restent réellement sans numéro ;
+- deployment/operations n'est pas artificiellement fixé à `0.4.0` ou `0.5.0` ;
+- `007-V0_1_1_START_PROMPT.md` ne doit être exécuté qu'après `v0.1.0` publié et vérifié ;
+- aucun profil, skeleton technique ou script d'audit n'est ajouté/modifié dans cette tranche.
+
+## Transition
+
+PASS : produire `history/0.1.0/beta.1.md`, fermer la tranche avec le handoff opérateur automatique, puis préparer `0.1.0-rc.1`.
+
+FAIL : conserver le résultat réel dans le history et corriger par `beta.1.fix.N` ou REPLAN si la revue macro elle-même doit changer.
--- a/deltas/0.1.0/rc.1.md
+++ b/deltas/0.1.0/rc.1.md
@@ -0,0 +1,333 @@
+<!-- file: deltas/0.1.0/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0-rc.1 — gel du scope et gate de release candidate
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.0-beta.1`, réalisé après application de `history/0.1.0/beta.1.md` avec statut `PASS`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.0-beta.1
+```
+
+Version après application :
+
+```text
+0.1.0-rc.1
+```
+
+## Objet et gel
+
+La RC gèle le scope fonctionnel de `0.1.0` sur :
+
+- la fondation de gouvernance et les skeleton specifications réutilisables ;
+- le socle Rust/Cargo, ses cinq templates techniques et les dry-runs `NEW` / `ADOPTION` ;
+- le contrat d'adoption de projets existants `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- la convention de clôture stable `rel.N` sans zéro de padding et l'identité du premier commit stable `X.Y.Z` ;
+- le handoff automatique des commandes opérateur, du commit/push au tag et à la preuve `publish.*` ;
+- la revue d'horizon validée et le prompt `007` vers `0.1.1`.
+
+Le changelog reçoit une entrée candidate `0.1.0` orientée utilisateurs. `ROADMAP.md`, `RULES.md`, les owners, profils, templates techniques, skeletons et scripts d'audit sont vérifiés mais non modifiés.
+
+Aucun scope Web, Java/Gradle, Android, Tauri, WASM, serveur Rust, Games/KSP ou deployment/operations n'entre fonctionnellement dans cette RC au-delà des décisions de trajectoire déjà validées.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+CHANGELOG.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/rc.1.md
+```
+
+DELETE : aucun.
+
+Le history `beta.1` est livré séparément et MUST être appliqué/committé avant ce delta.
+
+## Gate opérateur de release candidate
+
+Après application du history `PASS` de `beta.1`, commit/push de `beta.1`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.0-rc.1'
+git cat-file -e HEAD:history/0.1.0/beta.1.md
+test -f history/0.1.0/beta.1.md
+test -f deltas/0.1.0/rc.1.md
+test -f prompts/007-V0_1_1_START_PROMPT.md
+test ! -e history/0.1.0/rc.1.md
+
+grep -A2 '^## Statut$' history/0.1.0/beta.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 10 -->' CHANGELOG.md
+grep -Fx '## 0.1.0 (candidate)' CHANGELOG.md
+grep -Fx '<!-- version: 9 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+grep -Fx '<!-- version: 9 -->' ROADMAP.md
+grep -Fx '<!-- version: 1 -->' prompts/007-V0_1_1_START_PROMPT.md
+```
+
+Contrôle d'intégration de la RC :
+
+```bash
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+expected = {
+    "alpha.1.md": "PASS",
+    "alpha.2.md": "FAIL",
+    "alpha.2.fix.1.md": "PASS",
+    "alpha.3.md": "FAIL",
+    "alpha.3.fix.1.md": "PASS",
+    "alpha.4.md": "PASS",
+    "alpha.5.md": "PASS",
+    "beta.1.md": "PASS",
+}
+
+histories = {path.name for path in Path("history/0.1.0").glob("*.md")}
+assert histories == set(expected), histories
+for name, status in expected.items():
+    text = Path("history/0.1.0", name).read_text(encoding="utf-8")
+    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
+
+deltas = {path.name for path in Path("deltas/0.1.0").glob("*.md")}
+assert deltas == set(expected) | {"rc.1.md"}, deltas
+
+changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
+assert "## 0.1.0 (candidate)" in changelog
+section = changelog.split("## 0.1.0 (candidate)", 1)[1].split("## 0.0.5", 1)[0]
+for phrase in (
+    "première baseline PGR réellement réutilisable",
+    "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
+    "rel.N",
+    "publish.*",
+    "frontend Web",
+):
+    assert phrase in section, phrase
+for forbidden in ("alpha.2", "alpha.3", "beta.1", "rc.1"):
+    assert forbidden not in section, forbidden
+
+workflow = Path("docs/rules/210-WORKFLOW.md").read_text(encoding="utf-8")
+for phrase in (
+    "La famille `rel.N` utilise la représentation sans zéro de padding",
+    "première de ces tranches qui obtient réellement `PASS` est incluse dans le commit stable `X.Y.Z`",
+    "Le rapport `publish.*` est produit seulement à partir des artefacts et preuves réellement disponibles après publication.",
+    "../templates/006-OPERATOR_COMMAND_HANDOFF.md",
+):
+    assert phrase in workflow, phrase
+
+adoption = Path("docs/rules/230-ADOPTION.md").read_text(encoding="utf-8")
+for phrase in ("ADOPT", "KEEP-LOCAL", "OVERRIDE", "DEFER", "Préservation de l’historique"):
+    assert phrase in adoption, phrase
+
+rust_dryrun = Path("docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md").read_text(encoding="utf-8")
+assert "NEW       nouveau projet" in rust_dryrun
+assert "ADOPTION  projet existant" in rust_dryrun
+
+roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
+for version in ("0.1.1", "0.1.2", "0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
+    assert f"- `( ) {version}`" in roadmap, version
+assert "- `( ) 0.1.8`" not in roadmap
+assert "WASM" in roadmap
+assert "serveur Web Rust / Actix Web ou alternative" in roadmap
+assert "deployment & operations" in roadmap
+
+prompt = Path("prompts/007-V0_1_1_START_PROMPT.md").read_text(encoding="utf-8")
+for phrase in (
+    "archive source téléchargée depuis le tag Gitea `v0.1.0`",
+    "pgr-0.1.0-publish.001-report.md",
+    "0.1.1-alpha.1",
+    "games-v0.3.6.zip",
+    "TypeScript",
+    "Vite",
+    "Sass/CSS",
+    "Le skeleton Tauri reste `DEFER` pendant cette release.",
+):
+    assert phrase in prompt, phrase
+
+plan = Path("docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md").read_text(encoding="utf-8")
+assert "### beta.1 — réconciliation finale et revue d'horizon\n\nStatut opérateur : **PASS**." in plan
+assert "### rc.1 — release candidate\n\nStatut opérateur : **à valider**." in plan
+assert "État : **validée `PASS` par la gate opérateur de `beta.1`**." in plan
+
+print("0.1.0 rc.1 integration audit: clean (8 prior histories, frozen reusable baseline, candidate changelog, horizon and prompt 007 verified)")
+PYGATE
+```
+
+Rejouer également les deux chemins Rust/Cargo avec la toolchain réelle :
+
+```bash
+python3 -B - <<'PYRUST'
+from pathlib import Path
+import hashlib
+import shutil
+import subprocess
+import tempfile
+import tomllib
+
+cargo = shutil.which("cargo")
+if cargo is None:
+    raise SystemExit("BLOCKED: cargo is required for the 0.1.0 RC Rust/Cargo release gate")
+
+commands = (
+    [cargo, "metadata", "--format-version", "1", "--no-deps"],
+    [cargo, "fmt", "--all", "--", "--check"],
+    [cargo, "check", "--workspace"],
+    [cargo, "clippy", "--workspace", "--all-targets", "--all-features", "--", "-D", "warnings"],
+)
+
+source = Path("templates/rust-cargo")
+with tempfile.TemporaryDirectory(prefix="pgr-rc1-new-") as temporary:
+    root = Path(temporary)
+    (root / ".cargo").mkdir(parents=True)
+    (root / "crates/pgr-rc-core-lib/src").mkdir(parents=True)
+    shutil.copy2(source / "Cargo.toml", root / "Cargo.toml")
+    shutil.copy2(source / "clippy.toml", root / "clippy.toml")
+    shutil.copy2(source / "rustfmt.toml", root / "rustfmt.toml")
+    shutil.copy2(source / ".cargo/config.toml", root / ".cargo/config.toml")
+    shutil.copy2(source / "crates/project-core-lib/Cargo.toml", root / "crates/pgr-rc-core-lib/Cargo.toml")
+
+    workspace = (root / "Cargo.toml").read_text(encoding="utf-8")
+    workspace = workspace.replace("crates/project-core-lib", "crates/pgr-rc-core-lib")
+    workspace = workspace.replace('version = "0.1.0"', 'version = "9.9.9"')
+    (root / "Cargo.toml").write_text(workspace, encoding="utf-8")
+
+    member = (root / "crates/pgr-rc-core-lib/Cargo.toml").read_text(encoding="utf-8")
+    member = member.replace("project-core-lib", "pgr-rc-core-lib")
+    (root / "crates/pgr-rc-core-lib/Cargo.toml").write_text(member, encoding="utf-8")
+
+    config = (root / ".cargo/config.toml").read_text(encoding="utf-8")
+    config = config.replace("project-name", "pgr-rc1-new")
+    (root / ".cargo/config.toml").write_text(config, encoding="utf-8")
+
+    (root / "crates/pgr-rc-core-lib/src/lib.rs").write_text(
+        "//! Minimal source used only by the PGR RC dry-run.\n\n"
+        "/// Returns the RC marker.\n"
+        "#[must_use]\n"
+        "pub const fn rc_marker() -> u32 {\n"
+        "    return 1;\n"
+        "}\n",
+        encoding="utf-8",
+    )
+
+    for path in (
+        root / "Cargo.toml",
+        root / "clippy.toml",
+        root / "rustfmt.toml",
+        root / ".cargo/config.toml",
+        root / "crates/pgr-rc-core-lib/Cargo.toml",
+    ):
+        with path.open("rb") as handle:
+            tomllib.load(handle)
+        text = path.read_text(encoding="utf-8")
+        assert "project-name" not in text
+        assert "project-core-lib" not in text
+
+    for command in commands:
+        subprocess.run(command, cwd=root, check=True)
+
+with tempfile.TemporaryDirectory(prefix="pgr-rc1-adoption-") as temporary:
+    root = Path(temporary)
+    (root / "crates/legacy-core-lib/src").mkdir(parents=True)
+    (root / "Cargo.toml").write_text(
+        '[workspace]\nresolver = "3"\nmembers = ["crates/legacy-core-lib"]\n\n'
+        '[workspace.package]\nversion = "2.3.4"\nedition = "2024"\npublish = false\n',
+        encoding="utf-8",
+    )
+    (root / "rustfmt.toml").write_text('edition = "2024"\nmax_width = 120\n', encoding="utf-8")
+    (root / "crates/legacy-core-lib/Cargo.toml").write_text(
+        '[package]\nname = "legacy-core-lib"\nversion.workspace = true\nedition.workspace = true\npublish.workspace = true\n',
+        encoding="utf-8",
+    )
+    (root / "crates/legacy-core-lib/src/lib.rs").write_text(
+        "//! Existing synthetic library.\n\n"
+        "/// Returns the existing marker.\n"
+        "#[must_use]\n"
+        "pub const fn existing_marker() -> u32 {\n"
+        "    7\n"
+        "}\n",
+        encoding="utf-8",
+    )
+
+    protected = (root / "Cargo.toml", root / "rustfmt.toml", root / "crates/legacy-core-lib/Cargo.toml")
+    before = {path: hashlib.sha256(path.read_bytes()).hexdigest() for path in protected}
+    decisions = {
+        "510-RUST_CARGO": "ADOPT",
+        "rustfmt.max_width=120": "KEEP-LOCAL",
+        "PGR external artifact configuration": "DEFER",
+        "strict crate-root export audit": "DEFER",
+    }
+    assert set(decisions.values()) <= {"ADOPT", "KEEP-LOCAL", "OVERRIDE", "DEFER"}
+
+    for command in commands:
+        subprocess.run(command, cwd=root, check=True)
+
+    after = {path: hashlib.sha256(path.read_bytes()).hexdigest() for path in protected}
+    assert before == after
+    assert "max_width = 120" in (root / "rustfmt.toml").read_text(encoding="utf-8")
+
+print("0.1.0 rc.1 Rust/Cargo release dry-runs: clean (NEW and ADOPTION accepted by Cargo/rustfmt/Clippy)")
+PYRUST
+```
+
+Puis la suite PGR complète :
+
+```bash
+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 CHANGELOG.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/rc.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope attendu avant ajout du history est exactement :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.0/rc.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le changelog décrit les capacités de `0.1.0` et non ses tranches internes ;
+- aucune règle/profil/template/skeleton/audit fonctionnel nouveau n'entre dans la RC ;
+- `ROADMAP.md` conserve `0.1.0` en cours jusqu'à la promotion stable ;
+- `0.1.1..0.1.7` restent la trajectoire engagée et les domaines non numérotés restent réellement différés ;
+- le prompt `007` exige bien l'archive taggée `v0.1.0` et le rapport `publish.001` seulement lorsqu'il existe réellement avec statut `PASS` ;
+- la RC n'est ni le commit stable `0.1.0`, ni le tag `v0.1.0`, ni la vérification post-tag.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.1.0/rc.1.md`, l'appliquer puis committer/pousser `0.1.0-rc.1` avant le delta stable `rel.1`.
+
+### FAIL
+
+Consigner l'échec réel dans `history/0.1.0/rc.1.md` puis corriger uniquement le scope gelé dans `rc.1.fix.1`, sauf REPLAN si la candidate révèle un défaut fonctionnel plus large.
--- a/deltas/0.1.0/rel.1.md
+++ b/deltas/0.1.0/rel.1.md
@@ -0,0 +1,202 @@
+<!-- file: deltas/0.1.0/rel.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.0 rel.1 — promotion stable pré-tag
+
+## Baseline et version
+
+Baseline : `0.1.0-rc.1`, avec `history/0.1.0/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Version avant application :
+
+```text
+0.1.0-rc.1
+```
+
+Version après application :
+
+```text
+0.1.0
+```
+
+`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
+
+## Objet
+
+Promouvoir mécaniquement la RC validée vers la stable `0.1.0` sans rouvrir le scope fonctionnel.
+
+La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `006` historique. Aucun owner, profil, template, skeleton, script d'audit ou contrat technique n'est modifié.
+
+La validation de cette tranche est **pré-tag**. Le tag `v0.1.0`, son archive source Gitea et le rapport `pgr-0.1.0-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.0` et la publication réelle du tag.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.0/rel.1.md
+```
+
+DELETE : aucun.
+
+Le history `rc.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
+
+## Validation opérateur pré-tag
+
+Après application sur le commit contenant `history/0.1.0/rc.1.md` :
+
+```bash
+test "$(cat VERSION)" = '0.1.0'
+git cat-file -e HEAD:history/0.1.0/rc.1.md
+test -f history/0.1.0/rc.1.md
+test -f deltas/0.1.0/rel.1.md
+test -f prompts/007-V0_1_1_START_PROMPT.md
+test ! -e history/0.1.0/rel.1.md
+
+grep -A2 '^## Statut$' history/0.1.0/rc.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 16 -->' README.md
+grep -Fx '<!-- version: 10 -->' ROADMAP.md
+grep -Fx '<!-- version: 11 -->' CHANGELOG.md
+grep -Fx '<!-- version: 23 -->' docs/000-README.md
+grep -Fx '<!-- version: 10 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+grep -F -- '- `(x) 0.1.0`' ROADMAP.md
+grep -Fx '## 0.1.0' CHANGELOG.md
+grep -F 'première baseline réutilisable stable' README.md
+grep -F 'plan historique de la stable `0.1.0`' docs/000-README.md
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+expected = {
+    "alpha.1.md": "PASS",
+    "alpha.2.md": "FAIL",
+    "alpha.2.fix.1.md": "PASS",
+    "alpha.3.md": "FAIL",
+    "alpha.3.fix.1.md": "PASS",
+    "alpha.4.md": "PASS",
+    "alpha.5.md": "PASS",
+    "beta.1.md": "PASS",
+    "rc.1.md": "PASS",
+}
+
+for name, status in expected.items():
+    delta = Path("deltas/0.1.0", name)
+    history = Path("history/0.1.0", name)
+    assert delta.is_file(), name
+    assert history.is_file(), name
+    text = history.read_text(encoding="utf-8")
+    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
+
+pending = {path.name for path in Path("deltas/0.1.0").glob("*.md")} - {
+    path.name for path in Path("history/0.1.0").glob("*.md")
+}
+assert pending == {"rel.1.md"}, pending
+
+roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
+assert "- `(x) 0.1.0`" in roadmap
+for version in ("0.1.1", "0.1.2", "0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
+    assert f"- `( ) {version}`" in roadmap, version
+assert "- `( ) 0.1.8`" not in roadmap
+
+changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
+assert "## 0.1.0" in changelog.splitlines()
+assert "## 0.1.0 (candidate)" not in changelog
+assert "produit produit" not in changelog
+
+readme = Path("README.md").read_text(encoding="utf-8")
+assert "première baseline réutilisable stable" in readme
+assert "plan historique de la première baseline réutilisable `0.1.0`" in readme
+
+index = Path("docs/000-README.md").read_text(encoding="utf-8")
+assert "plan historique de la stable `0.1.0`" in index
+
+plan = Path("docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md").read_text(encoding="utf-8")
+assert "Statut opérateur : **PASS**." in plan
+assert "history/0.1.0/rel.1.md" in plan
+assert "pgr-0.1.0-publish.001-report.md" in plan
+
+prompt = Path("prompts/007-V0_1_1_START_PROMPT.md").read_text(encoding="utf-8")
+assert "tag Gitea `v0.1.0`" in prompt
+assert "pgr-0.1.0-publish.001-report.md" in prompt
+assert "0.1.1-alpha.1" in prompt
+
+workflow = Path("docs/rules/210-WORKFLOW.md").read_text(encoding="utf-8")
+assert "history rel.1 FAIL / PARTIAL / BLOCKED" in workflow
+assert "premier history rel.N[/fix.M] PASS qui établit réellement la stable" in workflow
+assert "commit X.Y.Z" in workflow
+
+print("0.1.0 rel.1 stable gate audit: clean (9 prior histories, rel.1 pending, stable presentation and post-tag handoff coherent)")
+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 README.md ROADMAP.md CHANGELOG.md docs/000-README.md \
+    docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
+    deltas/0.1.0/rel.1.md
+git diff --cached --check
+git status --short
+```
+
+Le scope attendu avant ajout du history est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.0/rel.1.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Les deux dry-runs Rust/Cargo ont été reconfirmés en `rc.1` avec Cargo/rustfmt/Clippy et aucun artefact Rust/Cargo n'est modifié par `rel.1`; ils ne sont donc pas rejoués une troisième fois dans la promotion mécanique. La suite Python PGR et les audits documentaires restent exécutés dans la gate stable.
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le scope fonctionnel de `rc.1` ne change pas ;
+- `0.1.0` est présenté comme stable de manière cohérente dans VERSION/README/ROADMAP/CHANGELOG/index/plan ;
+- les `FAIL` historiques `alpha.2` et `alpha.3` restent conservés avec leurs fixes `PASS` ;
+- la roadmap engagée `0.1.1` à `0.1.7` reste intacte ;
+- WASM, serveur Rust et deployment/operations restent non numérotés ;
+- le prompt `007` reste conditionnel à une vraie publication de `v0.1.0` et à un rapport post-tag `PASS` réel ;
+- aucune preuve post-tag n'est anticipée.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.1.0/rel.1.md`, l'appliquer, puis créer le commit stable sous le message exact :
+
+```text
+0.1.0
+```
+
+Après push de la branche canonique, créer et publier le tag annoté `v0.1.0`. Vérifier localement et à distance l'objet tag et son commit déréférencé. Télécharger ensuite l'archive source depuis le tag Gitea et la fournir au générateur avec les sorties Git de publication afin de produire `pgr-0.1.0-publish.001-report.md` à partir de preuves réelles.
+
+Le prompt `007-V0_1_1_START_PROMPT.md` n'est remis comme reprise effective de `0.1.1` qu'après un rapport post-tag `PASS`.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.0/rel.1.md`, ne pas créer le tag et corriger uniquement la fermeture dans `rel.1.fix.1` avant toute publication.
--- a/docs/000-README.md
+++ b/docs/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 17 -->
+<!-- version: 23 -->

 # Documentation PGR

@@ -20,6 +20,16 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`

 Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.

+## Points d'entrée de 0.1.0
+
+- [`plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la stable `0.1.0`, depuis l’audit de `v0.0.5` jusqu’à la baseline réutilisable, la clôture/publication et la revue d’horizon.
+- [`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.
+- [`validation/004-RUST_CARGO_BASELINE_DRY_RUN.md`](validation/004-RUST_CARGO_BASELINE_DRY_RUN.md) — contrat de dry-run temporaire pour vérifier la composition d’un nouveau workspace Rust/Cargo et l’adoption non destructive d’un workspace existant.
+- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue d’horizon de `beta.1` engageant `0.1.1` à `0.1.7` par domaines cohérents et laissant WASM, serveur Rust et deployment sans réservation prématurée.
+- [`../prompts/007-V0_1_1_START_PROMPT.md`](../prompts/007-V0_1_1_START_PROMPT.md) — prompt de reprise préparé pour la fondation frontend Web `0.1.1`, à utiliser seulement après publication et vérification post-tag de `0.1.0`.
+
 ## Points d'entrée de 0.0.5

 - [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — périmètre et décisions de la release `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
@@ -0,0 +1,310 @@
+<!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
+<!-- version: 10 -->
+
+# Plan 0.1.0 — première baseline PGR réutilisable
+
+## Statut et sources
+
+Plan actif créé pendant `0.1.0-alpha.1` conformément à `prompts/006-V0_1_0_START_PROMPT.md` après audit indépendant de la stable taggée `v0.0.5` et de son rapport post-tag.
+
+Sources autoritaires de reprise :
+
+```text
+pgr-v0.0.5.zip                       1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49
+pgr-0.0.5-publish.001-report.md      a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96
+```
+
+Le rapport `publish.001` est `PASS` et porte sur cette même archive. L'absence de `.git` dans l'archive du tag est normale et n'est pas une validation manquante.
+
+Deux corpus récents ont également été fournis pour préparer l'adoption future sans devenir des dépendances de la baseline `0.1.0` :
+
+```text
+games-v0.3.6.zip                     ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
+```
+
+Games `0.3.6` conserve explicitement `0.3.7` comme future release d'alignement PGR. KSP `0.3.16` reste principalement un corpus Rust/Cargo avec six applications Tauri ; aucune migration de Games ou KSP n'appartient à `0.1.0`.
+
+## Audit de la stable `v0.0.5`
+
+### Intégrité et chaîne historique
+
+L'archive stable contient `225` entrées sous une racine unique `pgr/`, soit `194` fichiers et `31` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
+
+Les `62` couples delta/history des releases `0.0.1` à `0.0.5` sont complets :
+
+```text
+0.0.1  12 / 12
+0.0.2  12 / 12
+0.0.3  10 / 10
+0.0.4   9 / 9
+0.0.5  19 / 19
+```
+
+La vérité opérateur de `0.0.5` est conservée, notamment les `FAIL` intermédiaires et la fermeture finale `rel.001.fix.1` en `PASS`. Aucun ancien delta/history ne sera renommé rétroactivement lorsque la nouvelle convention `rel.N` sera introduite.
+
+### Tests et audits
+
+La stable passe :
+
+```text
+python3 -B -m unittest discover -s tests -v
+48 tests PASS
+
+Markdown header audit: clean (171 file(s))
+Markdown table audit:  clean (8 table(s), 171 file(s))
+Markdown link audit:   clean (161 local link(s), 171 file(s))
+```
+
+Les audits PGR restent monotâches et read-only : trois audits Markdown, six audits de style Rust, un audit Rust de façade/export completeness, plus leur helper commun. Aucun audit ne devient un wrapper de build.
+
+### Règles, profils, templates et skeletons
+
+La hiérarchie normative est cohérente et possède un owner explicite pour gouvernance, workflow, skeletons, documentation, validation, langages/écosystèmes, plateformes et frameworks.
+
+Profils techniques déjà matérialisés :
+
+```text
+510  Rust / Cargo
+520  Java / Maven / Gradle
+610  Android
+710  Tauri 2
+```
+
+La baseline possède cinq templates techniques Rust/Cargo sous `templates/rust-cargo/`, deux skeleton specifications concrètes — fondation de gouvernance et workspace Rust/Cargo — et les contrats de validation associés.
+
+Le profil Rust/Cargo est suffisamment avancé pour servir rapidement de référence à Games et KSP. Les profils Java/Gradle et Android existent déjà normativement ; leur future release `0.1.x` devra donc d'abord réévaluer leur complétude pratique, leurs templates, skeletons et audits nécessaires au cas Games au lieu de recréer les profils depuis zéro.
+
+Le profil Tauri `710` existe également, mais le skeleton Tauri contrôlé reste volontairement `DEFER` : il attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS, sorties frontend et validation frontend indépendante.
+
+## Défauts de gouvernance à corriger en 0.1.0
+
+L'audit ne révèle pas de défaut bloquant de la stable, mais deux conventions doivent être corrigées avant de diffuser PGR plus largement.
+
+### Clôture stable `rel.N`
+
+L'expérience réelle de `0.0.5` montre que la convention actuelle `rel.001` mélange inutilement padding historique et identité de tranche. La convention future doit utiliser :
+
+```text
+rel.1
+rel.1.fix.1
+rel.2
+...
+```
+
+Les anciens fichiers `rel.001*` restent immuables.
+
+Le nom de tranche et le message du commit qui matérialise finalement la stable doivent être distingués. Par défaut PGR :
+
+```text
+rel.1 FAIL              -> commit de tranche X.Y.Z-rel.1
+rel.1.fix.1 FAIL        -> commit de tranche X.Y.Z-rel.1.fix.1
+première tranche qui obtient le PASS stable
+                         -> commit final X.Y.Z
+```
+
+Le tag `vX.Y.Z` n'est créé qu'après ce commit final stable.
+
+### Commandes opérateur et publication
+
+Après production d'un history constaté, le générateur doit remettre spontanément les commandes exactes à exécuter entre l'application de ce history et le delta suivant. Le défaut PGR retenu est :
+
+```bash
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "<message attendu>"
+git push origin <branche>
+```
+
+Le bloc doit être adapté au projet et au statut réel de la tranche ; il ne doit pas inventer une branche ou un remote lorsqu'ils ne sont pas établis.
+
+Pour la dernière clôture pré-tag, le handoff opérateur doit en plus fournir le bloc de tag/vérification approprié et indiquer explicitement les preuves/artefacts à remettre pour générer la vérification post-tag, notamment l'archive issue du tag et les preuves Git réellement disponibles. Un tag annoté doit être vérifié sans confondre l'objet tag avec son commit déréférencé.
+
+Après `publish.* PASS`, la consigne manuelle de nouvelle session reste produite automatiquement selon `docs/templates/003-NEW_SESSION_PROMPT.md`.
+
+## Mission de `0.1.0`
+
+`0.1.0` doit transformer la fondation `0.0.x` en baseline réellement réutilisable **sans absorber les domaines technologiques futurs**.
+
+La release doit :
+
+1. corriger la sémantique de clôture `rel.N` et des commits stables ;
+2. rendre obligatoire le handoff automatique des commandes opérateur après chaque history et lors de la publication ;
+3. formaliser une adoption proportionnée de PGR par un projet existant, distincte de l'instanciation d'un nouveau projet ;
+4. vérifier que la fondation et le skeleton Rust/Cargo peuvent servir de baseline réutilisable sans dépendre de choix KSP/Games ;
+5. effectuer avant RC une revue d'horizon qui engage uniquement les prochaines releases `0.1.x` suffisamment décidées.
+
+`0.1.0` ne crée pas de profil Web, WASM, serveur Rust/Actix, Java, Android ou Tauri supplémentaire. Ces domaines seront traités séparément dans la série `0.1.x` lorsque leur release dédiée sera engagée.
+
+## Direction acquise pour la série `0.1.x`
+
+La série `0.1.x` doit rester composée de releases concrètes indépendantes, en pratique une release/session par domaine cohérent. Il est explicitement exclu de regrouper Web, serveur Rust, Java/Android, Tauri et WASM dans `0.1.0` ou dans une unique grosse release suivante.
+
+La revue d'horizon de `0.1.0` devra ordonner et, seulement lorsque le scope est suffisamment décidé, numéroter les axes suivants :
+
+- owners Web contrôlés : TypeScript, Vite, Sass/CSS, package manager/build outputs et validation frontend ;
+- serveur Web Rust — Actix Web ou autre framework seulement à partir d'un besoin et d'un corpus réels, notamment pour les trajectoires HTTP/3 ;
+- réévaluation pratique du profil Java/Gradle existant pour Games ;
+- réévaluation pratique du profil Android existant pour Games ;
+- WASM comme domaine séparé si l'adoption Games démontre qu'un owner PGR apporte une valeur immédiate ;
+- levée du `DEFER` Tauri seulement après matérialisation des owners Web nécessaires ;
+- adoption de PGR par Games dès que le sous-ensemble requis est réellement prêt ;
+- adoption de PGR par KSP ensuite, avec une pression principalement Rust/Cargo + Tauri et sans attendre les profils non pertinents pour KSP.
+
+Les numéros exacts `0.1.1`, `0.1.2`, etc. ne sont pas réservés dans `alpha.1`. Cette attribution appartient à la revue d'horizon lorsque l'ordre réel est suffisamment décidé.
+
+Après cette vague d'adoption `0.1.x`, les axes plus larges — projets documentaires/spécifications tels que `saselang-bible`, généricité hors logiciel et autres familles technologiques — restent candidats pour une trajectoire `0.2.x`/`0.3.x` à décider ultérieurement, sans réservation artificielle aujourd'hui.
+
+Deux horizons supplémentaires sont acquis comme **candidats différés**, sans numéro réservé :
+
+- après application réelle de PGR à Games puis KSP, une release `0.1.x` non prioritaire pourra introduire des audits Python read-only reproduisant uniquement le sous-ensemble des conventions Rust/Clippy vérifiable statiquement sans Cargo ni `rustc`; ces audits devront utiliser les options PGR existantes, documenter explicitement les lints `FULL / LIMITED / UNSUPPORTED` et MUST NOT être présentés comme équivalents à `cargo clippy`, qui reste la validation autoritaire ;
+- à plus long terme, une série dédiée au déploiement et à l'exploitation devra être étudiée, potentiellement dans un horizon `0.4.x` ou `0.5.x` mais sans réservation actuelle : reverse proxies tels que Nginx/Apache, bases PostgreSQL/MySQL ou autres, conteneurs Docker/Compose, hébergement Linux/services, environnements et secrets, migrations/backup, health/observabilité et skeletons/audits de déploiement composables.
+
+Ces horizons ne modifient pas la mission de `0.1.0` et ne doivent pas être absorbés par les tranches courantes.
+
+## Trajectoire prévisionnelle de `0.1.0`
+
+### alpha.1 — audit de stable et plan
+
+Statut opérateur : **PASS**.
+
+La stable `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées ont été vérifiés. Le cadrage a été consigné sans changement normatif ni migration externe.
+
+### alpha.2 — clôture stable et identité `rel.N`
+
+Statut opérateur : **FAIL**.
+
+Le contenu normatif prévu a été matérialisé et le contrôle structurel spécifique a confirmé `rel.N` sans padding, la conservation des historiques `rel.001*` et l'identité explicite du commit stable. La gate livrée contenait toutefois des commandes `grep -F` entourées de quotes simples alors que certains motifs contenaient eux-mêmes des apostrophes (`n'utilise`, `l'exploitation`). Le shell a donc mal interprété plusieurs contrôles textuels.
+
+Le défaut appartient à la gate opérateur, pas aux owners `200-GOVERNANCE` / `210-WORKFLOW`. Le delta `alpha.2.md` reste immuable.
+
+### alpha.2.fix.1 — correction de la gate `rel.N`
+
+Statut opérateur : **PASS**.
+
+Le fix a conservé `200-GOVERNANCE.md`, `210-WORKFLOW.md` et le delta historique `alpha.2.md` inchangés. La preuve Python corrigée a reconfirmé la convention `rel.N`, le `FAIL` historique de `alpha.2`, les anciens artefacts `rel.001*` et l'indépendance de `publish.001`.
+
+La validation a exécuté `48/48` tests et les trois audits Markdown sans diagnostic. Aucun nouveau fix ni REPLAN n'est requis.
+
+### alpha.3 — handoff automatique des commandes opérateur
+
+Statut opérateur : **FAIL**.
+
+Le contenu prévu a été matérialisé : `210-WORKFLOW.md` possède le contrat normatif de remise automatique et `006-OPERATOR_COMMAND_HANDOFF.md` fournit la forme de rendu pour tranche ordinaire, échec + fix, clôture stable, tag et preuves `publish.*`. Les `48` tests et les trois audits Markdown sont restés propres.
+
+La gate spécifique n'a toutefois pas pu s'exécuter jusqu'au bout : le littéral Python `'## Fermeture d'une tranche non stable'` utilisait des quotes simples autour d'un texte contenant l'apostrophe de `d'une`, provoquant `SyntaxError: unterminated string literal`. Le défaut appartient à la gate ; aucun défaut normatif du workflow ou du template n'est établi.
+
+### alpha.3.fix.1 — correction de la gate du handoff opérateur
+
+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 : **PASS**.
+
+Le nouvel owner `230-ADOPTION.md` et le pattern `007-EXISTING_PROJECT_ADOPTION.md` ont été validés avec le mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, la migration progressive et la préservation de l’historique. Les `48` tests et les trois audits Markdown sont propres.
+
+Games et KSP restent des futurs consommateurs : aucune migration externe ni activation de profils non applicables n’a été introduite.
+
+### alpha.5 — baseline réutilisable et dry-run de composition
+
+Statut opérateur : **PASS**.
+
+La fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale ont été réconciliés. Les deux chemins du contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` ont été exécutés avec Cargo :
+
+```text
+NEW       PASS — metadata/fmt/check/clippy sur instanciation temporaire
+ADOPTION  PASS — workspace synthétique valide et choix KEEP-LOCAL / DEFER préservés
+```
+
+Les `48/48` tests PGR et les trois audits Markdown sont restés propres. Games et KSP n'ont pas été utilisés comme fixtures et aucun profil technologique supplémentaire n'a été absorbé par la tranche.
+
+### beta.1 — réconciliation finale et revue d'horizon
+
+Statut opérateur : **PASS**.
+
+La gate opérateur a confirmé la revue d'horizon, la roadmap `0.1.1` à `0.1.7`, le maintien des domaines différés sans numéro, le prompt `007` et les `48/48` tests PGR avec les trois audits Markdown propres.
+
+La revue d'horizon est matérialisée dans `003-V0_1_0_HORIZON_REVIEW.md`. Elle engage une séquence par domaines cohérents :
+
+```text
+0.1.1  Web frontend
+0.1.2  Java / Gradle
+0.1.3  Android
+0.1.4  Tauri contrôlé, sous condition de readiness Web
+0.1.5  adoption Games
+0.1.6  adoption KSP
+0.1.7  audits Rust/Clippy statiques Python-only
+```
+
+WASM, serveur Rust et deployment restent non numérotés. Le prompt `007-V0_1_1_START_PROMPT.md` est préparé pour la cible suivante mais ne devient exécutable qu'après publication de `v0.1.0` et vérification post-tag `PASS`.
+
+### rc.1 — release candidate
+
+Statut opérateur : **PASS**.
+
+La gate opérateur a confirmé le scope gelé, les huit histories antérieurs avec leurs statuts réels, les deux dry-runs Rust/Cargo via la toolchain réelle, le contrat d’adoption, la convention `rel.N`, le handoff opérateur, la roadmap et le prompt `007`. Les `48/48` tests et les trois audits Markdown sont propres. Aucun owner ni domaine technique nouveau n’est entré dans la RC.
+
+### rel.1 — promotion stable
+
+Première utilisation de la convention corrigée `rel.1`. La promotion est strictement mécanique : `VERSION = 0.1.0`, `ROADMAP.md` marque `0.1.0` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la baseline comme stable et le présent plan devient historique. Aucun owner, profil, template, skeleton ou script technique n’est modifié.
+
+Le résultat opérateur de cette tranche appartient à `history/0.1.0/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.0` avant le tag `v0.1.0`. La vérification post-tag reste séparée et doit produire `pgr-0.1.0-publish.001-report.md` uniquement à partir de l’archive et des preuves réellement publiées.
+
+## Stratégie de validation
+
+Chaque tranche documentaire rejoue au minimum :
+
+```text
+python3 -B -m unittest discover -s tests -v
+python3 -B scripts/audit_markdown_headers.py ...
+python3 -B scripts/audit_markdown_tables.py ...
+python3 -B scripts/audit_markdown_links.py ...
+```
+
+Les scripts d'audit restent read-only et ne déclenchent aucun build. Les changements de workflow doivent recevoir des contrôles structurels ciblés qui vérifient la nomenclature future sans imposer de renommer les snapshots historiques.
+
+Le dry-run de composition `alpha.5` doit privilégier les parsers/outils officiels lorsque disponibles. Une prévalidation générateur ne remplace pas le gate opérateur.
+
+## Déclencheurs de REPLAN
+
+REPLAN est requis si :
+
+- `0.1.0` commence à absorber Web, Android, WASM, Actix ou le skeleton Tauri au lieu de les laisser à des releases `0.1.x` distinctes ;
+- la convention de commit stable ne peut pas être définie sans ambiguïté avec les histories `FAIL`/fix ;
+- le handoff automatique dépend de valeurs Git qui ne peuvent pas être établies de manière sûre ;
+- l'adoption d'un projet existant exige de modifier rétroactivement son historique ;
+- le dry-run révèle que la fondation ou le skeleton Rust/Cargo n'est pas réellement autonome ;
+- la revue d'horizon transforme des candidats en numéros réservés sans scope suffisamment décidé.
+
+## Clôture et transition
+
+- documentation durable du workflow : `alpha.2` à `alpha.4` ;
+- preuve de réutilisabilité : `alpha.5` ;
+- réconciliation documentaire et revue d'horizon : `beta.1` ;
+- `CHANGELOG` candidate et release gate : `rc.1` ;
+- promotion stable et nouveau contrat `rel.1` : `rel.1` ;
+- tag/post-tag : après le commit stable `0.1.0`, avec handoff opérateur automatique ;
+- prompt suivant : créé uniquement si `beta.1` a réellement engagé la prochaine cible `0.1.x`.
+
+## Revue d'horizon
+
+État : **validée `PASS` par la gate opérateur de `beta.1`**.
+
+Décision proposée par la revue :
+
+- engager `0.1.1` Web frontend ;
+- engager séparément `0.1.2` Java/Gradle et `0.1.3` Android ;
+- engager `0.1.4` comme release de domaine Tauri, avec obligation de reconfirmer la readiness Web avant toute matérialisation de skeleton ;
+- engager `0.1.5` pour l'adoption Games puis `0.1.6` pour l'adoption KSP ;
+- engager `0.1.7` pour les audits Rust/Clippy statiques Python-only après retour réel des deux adoptions ;
+- conserver WASM et serveur Rust comme candidats sans numéro ;
+- conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure ;
+- conserver deployment/operations comme horizon majeur ultérieur sans réserver aujourd'hui `0.4.x` ou `0.5.x`.
+
+La revue complète et ses critères de réouverture sont possédés par `../studies/003-V0_1_0_HORIZON_REVIEW.md`.
--- 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/200-GOVERNANCE.md
+++ b/docs/rules/200-GOVERNANCE.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/200-GOVERNANCE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->

 # Governance rules

@@ -77,6 +77,8 @@ vX.Y.Z

 `rel.N` MAY identifier une livraison ou un artefact de clôture, mais MUST NOT être traité comme une version produit SemVer.

+Pour les nouvelles releases gouvernées par cette convention, `N` commence à `1` et sa représentation canonique n'utilise pas de zéro de padding : `rel.1`, `rel.2`, etc. Les formes historiques déjà publiées telles que `rel.001` restent des snapshots immuables et MUST NOT être renommées rétroactivement.
+
 Avant `1.0.0`, PGR recommande la convention suivante lorsqu'elle correspond au projet :

 - `X = 0` indique que le contrat public durable n'est pas encore stabilisé ;
@@ -126,6 +128,16 @@ La promotion stable MUST néanmoins exécuter son propre gate proportionné pour

 Le tag stable canonique est `vX.Y.Z`.

+La clôture opérationnelle `rel.N[/fix.M]` n'est pas une prerelease SemVer et MAY intervenir alors que `VERSION` porte déjà `X.Y.Z`. En l'absence d'une convention locale explicitement documentée, PGR impose la distinction suivante pour le message du commit de clôture :
+
+```text
+rel.1 FAIL / PARTIAL / BLOCKED          -> X.Y.Z-rel.1
+rel.1.fix.1 FAIL / PARTIAL / BLOCKED    -> X.Y.Z-rel.1.fix.1
+première tranche de clôture PASS        -> X.Y.Z
+```
+
+Le commit nommé `X.Y.Z` MUST inclure le history qui établit effectivement le `PASS` stable. Le tag `vX.Y.Z` MUST être créé seulement après ce commit. Une clôture échouée MUST rester identifiable par son nom de tranche et MUST NOT être présentée comme le commit stable final.
+
 La vérification d'une publication ou d'une archive produite après le tag est une preuve distincte de la validation pré-tag.

 ## Correctifs de tranche
--- a/docs/rules/210-WORKFLOW.md
+++ b/docs/rules/210-WORKFLOW.md
@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 5 -->
+<!-- version: 7 -->

 # Workflow artifact rules

@@ -86,6 +86,8 @@ alpha.3.md
 alpha.3.fix.1.md
 beta.1.md
 rc.1.md
+rel.1.md
+rel.1.fix.1.md
 ```

 Un delta MUST :
@@ -174,9 +176,63 @@ current delta changes

 doivent être présents, alors que le delta suivant MUST rester absent.

-Le message de commit MAY suivre les conventions du projet. PGR n'impose pas Conventional Commits, GitFlow ou une topologie universelle de branches.
+Pour une tranche alpha, beta, RC ou autre tranche qui n'établit pas la stable, le message de commit MAY suivre les conventions du projet tant que l'état et la tranche restent identifiables. PGR n'impose pas Conventional Commits, GitFlow ou une topologie universelle de branches.

-L'important est que l'état et la tranche restent identifiables et que le repository ne mélange pas deux tranches non clôturées.
+La clôture stable `rel.N[/fix.M]` possède une règle plus stricte afin de distinguer une tentative de fermeture de l'identité stable réellement obtenue. En l'absence d'un mapping local explicitement documenté :
+
+```text
+history rel.1 FAIL / PARTIAL / BLOCKED
+    -> commit X.Y.Z-rel.1
+
+history rel.1.fix.1 FAIL / PARTIAL / BLOCKED
+    -> commit X.Y.Z-rel.1.fix.1
+
+premier history rel.N[/fix.M] PASS qui établit réellement la stable
+    -> commit X.Y.Z
+```
+
+Le suffixe opérationnel n'est donc conservé dans le message du commit que tant que la clôture n'a pas obtenu le `PASS` stable. Le commit `X.Y.Z` MUST contenir le delta de clôture concerné et son history `PASS`; il MUST précéder le tag canonique `vX.Y.Z`.
+
+Un projet qui possède une convention de message différente MAY utiliser un mapping équivalent, mais il MUST conserver sans ambiguïté la distinction entre tentative de clôture échouée et commit stable final.
+
+Le repository ne doit jamais mélanger deux tranches non clôturées dans un même commit.
+
+## Remise automatique des commandes opérateur
+
+Après production d'un history destiné à être appliqué par l'opérateur, le générateur MUST remettre spontanément les commandes nécessaires pour fermer cette tranche. Il ne doit pas attendre une demande séparée du type « je commit avec quel message ? ».
+
+Lorsque les valeurs Git sont établies par le projet ou par les sorties opérateur de la session, le bloc remis MUST utiliser les valeurs réelles : archive history, message de commit, remote et branche. Le générateur MUST NOT inventer un remote, une branche ou une politique de tag non établis. Une valeur encore inconnue doit être signalée explicitement ou résolue par une commande de découverte sûre avant la commande qui en dépend.
+
+Pour une livraison ZIP et une tranche non stable, le handoff couvre normalement dans cet ordre :
+
+```text
+apply history archive
+    ↓
+git add / staged whitespace check / status
+    ↓
+commit avec le message attendu
+    ↓
+push de la branche courante
+    ↓
+apply du delta suivant ou du fix déjà livré
+```
+
+Lorsqu'un history `FAIL`, `PARTIAL` ou `BLOCKED` conduit à un `.fix.N`, le bloc de commandes ferme d'abord la tranche constatée sous son identité propre puis autorise seulement l'application du correctif. Lorsqu'un history `PASS` conduit à la tranche planifiée suivante, le même ordre s'applique.
+
+Pour la première clôture `rel.N[/fix.M]` qui établit réellement la stable, le bloc MUST utiliser le message de commit stable `X.Y.Z`, puis fournir séparément les commandes de tag et de vérification applicables. Le tag MUST NOT être créé avant le commit stable et son push lorsque le projet exige que la branche canonique distante porte d'abord ce commit.
+
+Le handoff de publication MUST également indiquer exactement ce que l'opérateur doit remettre au générateur pour produire la preuve post-tag applicable. Pour une archive source générée par la forge à partir du tag, cela inclut normalement :
+
+- le ZIP téléchargé depuis le tag canonique ;
+- le SHA du commit stable local observé avant ou pendant le tag ;
+- le commit déréférencé localement par le tag ;
+- la référence distante du tag ;
+- pour un tag annoté, le commit distant déréférencé `refs/tags/vX.Y.Z^{}` afin de ne pas confondre l'objet tag avec son commit ;
+- toute autre preuve explicitement requise par la politique locale de publication.
+
+Le rapport `publish.*` est produit seulement à partir des artefacts et preuves réellement disponibles après publication. Il MUST NOT être prérempli avec un `PASS` futur.
+
+[`../templates/006-OPERATOR_COMMAND_HANDOFF.md`](../templates/006-OPERATOR_COMMAND_HANDOFF.md) fournit le pattern de rendu des blocs de commandes. Il complète le présent contrat sans devenir une seconde source normative.

 ## Manifest de suppression

@@ -327,9 +383,11 @@ published source archive
 post-tag verification
 ```

-Un identifiant opérationnel tel que `rel.001` ou `publish.001` MAY être utilisé pour distinguer une clôture ou une vérification de publication sans devenir une nouvelle version SemVer produit.
+Un identifiant opérationnel tel que `rel.1` ou `publish.001` MAY être utilisé pour distinguer une clôture ou une vérification de publication sans devenir une nouvelle version SemVer produit. La famille `rel.N` utilise la représentation sans zéro de padding définie par la gouvernance ; les anciennes formes `rel.001*` déjà publiées restent historiques et immuables.

-`rel.001` prouve l'état stable avant création du tag. Une preuve `publish.001`, lorsqu'elle existe, porte sur l'artefact réellement publié après le tag et reste donc extérieure au tag qu'elle vérifie. Elle ne revalide pas fonctionnellement la release.
+`rel.1` est la première tranche de clôture stable pré-tag d'une nouvelle release utilisant cette convention. Si elle échoue, `rel.1.fix.N` corrige uniquement cette fermeture. La première de ces tranches qui obtient réellement `PASS` est incluse dans le commit stable `X.Y.Z`, puis seulement le tag `vX.Y.Z` est créé.
+
+Une preuve `publish.001`, lorsqu'elle existe, porte sur l'artefact réellement publié après le tag et reste donc extérieure au tag qu'elle vérifie. Elle ne revalide pas fonctionnellement la release. La présente règle ne renomme pas `publish.001`; son identité reste indépendante de la correction `rel.001` -> `rel.1`.

 Lorsqu'un rapport `publish.001` est un prérequis de la session suivante, la clôture post-tag MUST indiquer explicitement à l'opérateur qu'il doit fournir ce rapport avec l'archive taggée. Le démarrage suivant effectue toujours son propre audit d'intake de la baseline ; il ne traite pas pour autant la stable précédente comme une release encore en attente de validation.

--- 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/skeletons/000-README.md
+++ b/docs/skeletons/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/000-README.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->

 # Index des skeleton specifications PGR

@@ -20,6 +20,8 @@ Une specification peut se composer avec une fondation plus générale, mais la c
 - [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable pour établir la gouvernance locale, la version, la documentation minimale, le workflow retenu et sa validation initiale sans imposer d'architecture applicative.
 - [`002-RUST_CARGO_WORKSPACE.md`](002-RUST_CARGO_WORKSPACE.md) — specialization composable d'un workspace Rust/Cargo fondée sur `001`, les profils `500 + 510`, les cinq templates Rust/Cargo et une validation réelle de la toolchain.

+Pour un projet existant, ces specifications servent de références de comparaison et non de recettes à recopier aveuglément. Le chemin canonique passe alors par [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et son mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`.
+
 Les familles Java/Android, Web, JNI et autres domaines sans pièces suffisantes restent différées tant que leurs owners normatifs et artefacts d'instanciation ne permettent pas une baseline réellement actionnable.

 Le skeleton Tauri a fait l'objet d'une décision explicite en `0.0.5-alpha.9` : le host Rust/Tauri est suffisamment cadré par `510` et `710`, mais PGR ne possède pas encore les owners Web/Vite/TypeScript/Sass nécessaires pour matérialiser proprement la stack frontend candidate des projets contrôlés. Aucun `003-TAURI...` n'est donc créé dans `0.0.5`. La décision et ses conditions de sortie sont enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
--- a/docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+++ b/docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->

 # Skeleton — Project governance foundation

@@ -17,6 +17,8 @@ Appliquer cette fondation lorsqu'un dépôt ou release unit veut utiliser PGR co

 Elle MAY servir de fondation à un skeleton spécialisé, qui ajoute ensuite uniquement les profils, templates, décisions et validations propres à son scope.

+Pour un projet déjà existant, cette specification devient une checklist de comparaison : l’adoption MUST suivre [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md), classifier les décisions applicables et préserver les choix locaux légitimes. Le pattern [`../templates/007-EXISTING_PROJECT_ADOPTION.md`](../templates/007-EXISTING_PROJECT_ADOPTION.md) peut matérialiser cette comparaison. Il ne faut pas réinstancier le dépôt comme s’il était vide.
+
 Ne pas l'appliquer comme cérémonie à un dépôt qui ne souhaite pas adopter le lifecycle ou les règles PGR. Elle ne transforme pas PGR en dépendance du projet destinataire.

 ## Owners sélectionnés
--- a/docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+++ b/docs/skeletons/002-RUST_CARGO_WORKSPACE.md
@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/002-RUST_CARGO_WORKSPACE.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->

 # Skeleton — Rust/Cargo workspace

@@ -29,6 +29,8 @@ La composition normale est :

 Un dépôt contenant plusieurs unités de release indépendantes ne doit pas être forcé dans un workspace à version globale fictive. Un framework, une plateforme, WASM, Android, Tauri, une FFI ou un autre scope plus spécifique peut ajouter ses propres règles sans modifier le contrat Rust/Cargo général.

+Pour un projet Rust/Cargo existant, ne pas appliquer ce skeleton comme une réinitialisation. Utiliser [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md), comparer le workspace réel avec la présente specification et classifier chaque écart utile en `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`. Les manifests ou fichiers d’outillage déjà fonctionnels ne sont remplacés que si la décision `ADOPT` le justifie réellement.
+
 ## Owners, guides et artefacts sélectionnés

 Les responsabilités générales de version, workflow, documentation et validation sont déjà couvertes par la fondation `001`. La présente specialization ajoute :
@@ -176,7 +178,7 @@ REVIEW dépendances/features, lints et métadonnées réellement nécessaires
 REVIEW aucune specialization plateforme/framework ajoutée sans besoin réel
 ```

-Pour valider les templates PGR eux-mêmes, une instanciation temporaire minimale peut remplacer les placeholders, créer une crate source triviale et exécuter les commandes Cargo ci-dessus. Cette preuve vérifie l'adoption des templates sans transformer le dépôt PGR en workspace Rust.
+Pour valider les templates PGR eux-mêmes, une instanciation temporaire minimale peut remplacer les placeholders, créer une crate source triviale et exécuter les commandes Cargo ci-dessus. Cette preuve vérifie l'adoption des templates sans transformer le dépôt PGR en workspace Rust. Le contrat réutilisable de cette preuve, ainsi que le dry-run distinct d’un projet existant, est documenté dans [`../validation/004-RUST_CARGO_BASELINE_DRY_RUN.md`](../validation/004-RUST_CARGO_BASELINE_DRY_RUN.md).

 Une prévalidation PGR ou générateur ne remplace jamais la gate opérateur autoritaire du projet destinataire.

--- a/docs/studies/000-README.md
+++ b/docs/studies/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->

 # Index des études PGR

@@ -11,3 +11,4 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti

 - [`001-KSP_GAMES_RECONCILIATION.md`](001-KSP_GAMES_RECONCILIATION.md) — première réconciliation explicite de PGR avec les baselines autoritaires fournies de `khadhroony-solana-project` et `sasedev-games`.
 - [`002-TAURI_SKELETON_DECISION.md`](002-TAURI_SKELETON_DECISION.md) — étude de readiness `alpha.9` déterminant si les owners existants suffisent à matérialiser un skeleton Tauri contrôlé sans transférer au skeleton la propriété normative du frontend.
+- [`003-V0_1_0_HORIZON_REVIEW.md`](003-V0_1_0_HORIZON_REVIEW.md) — revue d'horizon `0.1.0-beta.1` engageant les prochaines releases `0.1.x` suffisamment décidées et conservant les autres axes sans numéro.
--- a/docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+++ b/docs/studies/003-V0_1_0_HORIZON_REVIEW.md
@@ -0,0 +1,163 @@
+<!-- file: docs/studies/003-V0_1_0_HORIZON_REVIEW.md -->
+<!-- version: 1 -->
+
+# Revue d'horizon 0.1.0 — trajectoire d'adoption et owners techniques
+
+## Objet
+
+Cette étude matérialise la revue d'horizon obligatoire prévue par `0.1.0-beta.1`. Elle intervient après validation de la première baseline Rust/Cargo réutilisable et avant RC.
+
+Elle ne cherche pas à remplir artificiellement la roadmap. Elle engage seulement les releases `0.1.x` dont le domaine, l'ordre et les prérequis sont suffisamment décidés à partir des owners PGR existants et des corpus Games/KSP déjà audités.
+
+## État acquis à l'entrée
+
+`0.1.0-alpha.5` a démontré deux propriétés nécessaires à une adoption réelle :
+
+```text
+NEW       les templates Rust/Cargo peuvent instancier un workspace temporaire accepté par Cargo/rustfmt/Clippy
+ADOPTION  un workspace Rust existant peut conserver des décisions KEEP-LOCAL / DEFER sans copie destructive
+```
+
+Le contrat `230-ADOPTION.md` permet donc de migrer progressivement un dépôt réel sans attendre que PGR possède un owner pour chaque technologie rencontrée.
+
+Les profils suivants existent déjà :
+
+```text
+510  Rust / Cargo
+520  Java / Maven / Gradle
+610  Android
+710  Tauri 2
+```
+
+Le skeleton Tauri reste toutefois `DEFER` tant que les owners Web requis par `002-TAURI_SKELETON_DECISION.md` ne sont pas matérialisés.
+
+## Pression des corpus
+
+### Games
+
+La baseline Games fournie exerce déjà plusieurs domaines distincts :
+
+- Rust/Cargo ;
+- frontend Web avec TypeScript, Vite et Sass/CSS ;
+- Java/Gradle ;
+- Android/JNI/SDL ;
+- Tauri ;
+- WASM dans certains chemins ;
+- trajectoire serveur future, mais sans implémentation Actix Web autoritaire suffisante dans le corpus audité.
+
+Games possède déjà une future release locale `0.3.7` destinée à l'alignement PGR. PGR doit donc préparer rapidement les owners réellement nécessaires sans absorber tout le dépôt Games dans une seule release PGR.
+
+### KSP
+
+KSP exerce principalement Rust/Cargo et plusieurs applications Tauri. Son adoption ne doit pas attendre Java, Android, WASM ou un profil serveur qui ne lui sont pas nécessaires.
+
+L'ordre retenu reste Games avant KSP, afin que la première adoption large fournisse un retour d'expérience avant la migration du second corpus.
+
+## Releases `0.1.x` engagées
+
+### `0.1.1` — fondation frontend Web
+
+Domaine : Web frontend contrôlé.
+
+Scope attendu :
+
+- owner(s) TypeScript applicables ;
+- Vite et contrat dev/build outputs ;
+- Sass/CSS et statut des artefacts générés ;
+- package manager et lockfile classifiés sans imposer arbitrairement npm ;
+- validation frontend indépendante du host Tauri ;
+- templates/skeletons/audits uniquement lorsqu'un besoin réutilisable est démontré.
+
+Games est le corpus principal. Cette release ne crée pas le skeleton Tauri, n'intègre pas WASM et ne normalise pas encore un serveur Rust.
+
+### `0.1.2` — réévaluation Java / Gradle
+
+Domaine : Java et build Gradle génériques.
+
+Le profil `520-JAVA_MAVEN_GRADLE.md` existe déjà. La release doit le confronter à Games, séparer ce qui appartient à Java/Gradle de ce qui appartient à Android, puis créer uniquement les templates, validations ou audits génériques manquants.
+
+### `0.1.3` — réévaluation Android
+
+Domaine : Android.
+
+Le profil `610-ANDROID.md` existe déjà. La release doit l'éprouver sur le corpus Games, notamment autour du projet Gradle Android, des wrappers Java/JNI, des ressources et du packaging, sans transférer dans PGR les choix propres à un jeu ou à SDL lorsqu'ils ne sont pas génériques.
+
+### `0.1.4` — Tauri contrôlé
+
+Domaine : Tauri.
+
+Cette release réexamine formellement le `DEFER` actuel après `0.1.1`. Le skeleton Tauri contrôlé n'est matérialisé que si les conditions de sortie de `002-TAURI_SKELETON_DECISION.md` sont réellement satisfaites par les owners Web alors disponibles.
+
+Si ces conditions ne sont pas satisfaites, la release conserve explicitement le `DEFER` et REPLAN la suite au lieu de fabriquer un skeleton incomplet.
+
+### `0.1.5` — adoption de Games
+
+Domaine : adoption réelle de `sasedev-games`.
+
+Utiliser `230-ADOPTION.md` et `007-EXISTING_PROJECT_ADOPTION.md` pour établir la baseline autoritaire, mapper les owners PGR applicables et découper la migration. Les domaines non encore possédés par PGR peuvent rester `KEEP-LOCAL` ou `DEFER` ; l'adoption ne doit pas créer une obligation de normaliser WASM ou le serveur uniquement pour obtenir un statut global artificiel.
+
+### `0.1.6` — adoption de KSP
+
+Domaine : adoption réelle de `khadhroony-solana-project`.
+
+La pression principale attendue est Rust/Cargo + Tauri. La migration réutilise le retour d'expérience de Games et ne doit pas attendre les profils Java/Android/WASM/serveur non applicables.
+
+### `0.1.7` — audits Rust/Clippy statiques Python
+
+Domaine : prévalidation Rust dans un environnement Python-only.
+
+Cette release reste volontairement après les deux adoptions afin de dériver les contrôles de conventions réellement utiles observés dans PGR, Games et KSP.
+
+Les scripts :
+
+- sont read-only et non interactifs ;
+- fonctionnent sans Cargo ni `rustc` ;
+- réutilisent les options Rust/Clippy possédées par PGR au lieu d'inventer une politique parallèle ;
+- documentent chaque contrôle comme `FULL`, `LIMITED` ou `UNSUPPORTED` ;
+- ne présentent jamais un `PASS` Python comme équivalent à `cargo clippy PASS`.
+
+## Candidats laissés sans numéro
+
+### WASM
+
+Le corpus Games exerce WASM, mais la valeur d'un owner PGR séparé doit être confirmée pendant `0.1.5`. Aucun numéro n'est réservé maintenant.
+
+### Serveur Web Rust
+
+Actix Web ou une alternative reste un candidat à partir d'un corpus d'implémentation réel. La présence d'une trajectoire HTTP/3/WebTransport dans un roadmap projet ne suffit pas à normaliser aujourd'hui un framework serveur.
+
+### Projets documentaires et généricité hors logiciel
+
+`saselang-bible` reste un bon corpus futur pour tester PGR sur un projet documentaire/spécification. Cet axe, ainsi que la généricité hors logiciel, reste orienté vers une trajectoire `0.2.x` / `0.3.x` à décider ultérieurement.
+
+### Déploiement et exploitation
+
+Une future famille majeure devra traiter de manière composable les responsabilités de déploiement et d'exploitation : reverse proxy Nginx/Apache, PostgreSQL/MySQL ou autres bases, Docker/Compose, services Linux, environnements/secrets, migrations, backup/restore, health, observabilité et skeletons/audits de déploiement.
+
+Un horizon `0.4.x` ou `0.5.x` est plausible, mais aucun numéro précis n'est réservé tant que les séries intermédiaires n'ont pas déterminé le découpage réel.
+
+## Décision sur Tauri
+
+La décision `DEFER` de `002-TAURI_SKELETON_DECISION.md` reste vraie pendant `0.1.0`.
+
+La roadmap engage `0.1.4` comme release de domaine Tauri, pas comme autorisation anticipée de créer le skeleton. Son premier devoir sera de vérifier que `0.1.1` a effectivement fourni les owners Web nécessaires.
+
+## Prochaine cible
+
+La prochaine release PGR après publication de `0.1.0` est :
+
+```text
+0.1.1 — fondation frontend Web
+```
+
+Le prompt `prompts/007-V0_1_1_START_PROMPT.md` est donc préparé pendant `beta.1`, mais ne doit être exécuté qu'après stable `v0.1.0` et vérification post-tag `PASS`.
+
+## Critère de réouverture de la revue
+
+Une nouvelle revue macro est requise si :
+
+- `0.1.1` révèle que le domaine Web doit être scindé avant de pouvoir servir Tauri ;
+- Games ne peut pas être adopté avec `KEEP-LOCAL` / `DEFER` sans owner WASM ou serveur supplémentaire ;
+- `0.1.4` ne peut pas lever le `DEFER` Tauri ;
+- l'ordre Games puis KSP cesse d'être rationnel à cause d'une dépendance technique nouvellement démontrée ;
+- une release engagée perd son besoin réel ou doit être remplacée par une autre responsabilité.
--- a/docs/templates/001-RUST_CARGO_TOOLING.md
+++ b/docs/templates/001-RUST_CARGO_TOOLING.md
@@ -1,5 +1,5 @@
 <!-- file: docs/templates/001-RUST_CARGO_TOOLING.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->

 # Templates d'outillage Rust/Cargo

@@ -33,6 +33,8 @@ Adapter le header `# file:` de chacun à son nouveau chemin relatif. Comme il s'

 Le chemin de sortie sous `builds/` est externe au dépôt source ; il ne doit pas être inclus dans les archives du projet. Si l'environnement impose un autre emplacement, ajuster la configuration du projet au lieu de copier un chemin machine depuis KSP ou Games.

+Dans un projet existant, ces fichiers sont des références de comparaison. `rustfmt.toml`, `clippy.toml` ou `.cargo/config.toml` déjà présents MUST être comparés avant remplacement ; une différence locale peut rester `KEEP-LOCAL`, devenir un `OVERRIDE` explicite ou rester `DEFER` conformément à [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md). L’adoption n’exige pas une copie byte-for-byte des templates PGR.
+
 ## Validation dans un projet Rust

 Après adaptation, les contrôles utiles dépendent du code et des manifests effectivement présents :
--- a/docs/templates/002-CARGO_MANIFESTS.md
+++ b/docs/templates/002-CARGO_MANIFESTS.md
@@ -1,5 +1,5 @@
 <!-- file: docs/templates/002-CARGO_MANIFESTS.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->

 # Modèles de manifests Cargo workspace et crate membre

@@ -9,6 +9,8 @@ Le [manifest racine](../../templates/rust-cargo/Cargo.toml) est celui d'un works

 Ces modèles prolongent les trois configurations de [`001-RUST_CARGO_TOOLING.md`](001-RUST_CARGO_TOOLING.md). Le propriétaire des choix normatifs reste [`510-RUST_CARGO.md`](../rules/510-RUST_CARGO.md). Les chemins `project-core-lib`, le nom du package et la version `0.1.0` sont des **valeurs d'exemple à remplacer** : cette version ne reflète pas `VERSION` de PGR et ne définit pas la version d'un autre projet.

+Pour un projet existant, ne pas remplacer le manifest racine ou les manifests membres uniquement parce qu’ils diffèrent des exemples PGR. Les héritages, noms, membres, lints, métadonnées et dépendances sont d’abord comparés selon [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md), puis classifiés `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`. Le dry-run de [`../validation/004-RUST_CARGO_BASELINE_DRY_RUN.md`](../validation/004-RUST_CARGO_BASELINE_DRY_RUN.md) exerce séparément ce chemin non destructif.
+
 ## Adopter le manifest racine

 Copier `templates/rust-cargo/Cargo.toml` vers `Cargo.toml` du projet, corriger son header `# file:` et commencer sa propre révision de fichier à `1`. Adapter `members` aux répertoires qui existent effectivement, puis choisir la version canonique de l'unité de release. Lorsque toutes les crates partagent une seule release, aligner `[workspace.package].version` sur le `VERSION` de ce projet ; plusieurs unités de release indépendantes ne doivent pas hériter d'une version fictive commune.
--- a/docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+++ b/docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
@@ -0,0 +1,126 @@
+<!-- file: docs/templates/006-OPERATOR_COMMAND_HANDOFF.md -->
+<!-- version: 1 -->
+
+# Pattern — handoff des commandes opérateur
+
+## Usage
+
+Ce pattern matérialise la sortie opérateur exigée par [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md) après production d'un history et pendant une clôture stable. Son objectif est d'éviter que l'opérateur doive demander séparément quelles commandes exécuter entre le history reçu, son commit, le delta suivant et, pour une stable, le tag puis la vérification post-tag.
+
+Le pattern est un guide de rendu : `210-WORKFLOW.md` reste l'owner normatif.
+
+## Informations à résoudre avant le rendu
+
+Le générateur doit déterminer depuis les preuves disponibles :
+
+```text
+project
+X.Y.Z
+tranche courante
+statut du history
+archive history réellement livrée
+message de commit attendu
+remote Git établi
+branche Git établie
+delta/fix suivant déjà livré ou non
+stable obtenue ou non
+tag canonique attendu
+forge/archive post-tag applicable
+preuve publish.* attendue ou non
+```
+
+Une valeur non établie ne doit pas être inventée. Si le remote ou la branche manque, le rendu peut d'abord fournir une commande de découverte telle que `git remote -v` ou `git branch --show-current`, puis demander d'utiliser la valeur réellement observée ; il ne doit pas transformer silencieusement un exemple `origin/master` en règle universelle.
+
+## Fermeture d'une tranche non stable
+
+Lorsque le history est livré sous forme de ZIP et que remote/branche sont établis, le bloc remis suit cette forme :
+
+```bash
+unzip -o <project>-<X.Y.Z>-<tranche>.history.zip -d .
+
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "<message attendu>"
+git push <remote> <branche>
+```
+
+Si le delta suivant ou le fix est déjà livré dans la même réponse, son application est affichée **après** le bloc de commit/push :
+
+```bash
+unzip -o <archive delta suivante>.delta.zip -d .
+```
+
+L'ordre visuel du rendu doit refléter l'ordre autorisé : history → commit/push → delta suivant.
+
+## Tranche échouée suivie d'un fix
+
+Un `FAIL`, `PARTIAL` ou `BLOCKED` est d'abord committé avec l'identité de la tranche observée, puis le fix est appliqué. Exemple générique :
+
+```bash
+unzip -o <project>-<X.Y.Z>-alpha.2.history.zip -d .
+
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "X.Y.Z-alpha.2"
+git push <remote> <branche>
+
+unzip -o <project>-<X.Y.Z>-alpha.2.fix.1.delta.zip -d .
+```
+
+Le history `FAIL` n'est jamais remplacé par le futur `PASS` du fix.
+
+## Première clôture qui établit réellement la stable
+
+Quand `rel.N[/fix.M]` obtient le premier `PASS` stable, le commit porte l'identité produit :
+
+```bash
+unzip -o <project>-<X.Y.Z>-<rel.N[/fix.M]>.history.zip -d .
+
+git add -A
+git diff --cached --check
+git status --short
+git commit -m "X.Y.Z"
+git push <remote> <branche>
+```
+
+Le tag vient ensuite. Si la politique locale utilise un tag annoté, le bloc type est :
+
+```bash
+git status --short
+git rev-parse HEAD
+git tag -a vX.Y.Z -m "vX.Y.Z"
+git push <remote> vX.Y.Z
+
+git rev-list -n 1 vX.Y.Z
+git ls-remote --exit-code --tags <remote> refs/tags/vX.Y.Z
+git ls-remote <remote> 'refs/tags/vX.Y.Z^{}'
+```
+
+Pour un tag annoté, `refs/tags/vX.Y.Z` peut identifier l'objet tag et différer du SHA du commit. La référence déréférencée `refs/tags/vX.Y.Z^{}` est celle qui doit être comparée au commit stable.
+
+Si le projet utilise volontairement une autre forme de tag, le bloc est adapté à cette politique au lieu d'imposer `git tag -a`.
+
+## Remise nécessaire pour `publish.*`
+
+Après création/push du tag et génération de l'archive par la forge, le générateur indique explicitement ce qu'il attend. Pour le cas source-archive usuel :
+
+```text
+1. télécharger depuis la forge le ZIP correspondant exactement au tag vX.Y.Z ;
+2. fournir ce ZIP au générateur ;
+3. fournir les sorties Git du commit/tag local et distant exécutées ci-dessus ;
+4. fournir toute preuve de publication supplémentaire exigée localement.
+```
+
+Le générateur vérifie alors l'archive publiée, calcule son empreinte dans son propre environnement lorsque possible et produit le rapport `publish.*` à partir des observations réelles. Le rapport reste extérieur au tag qu'il vérifie.
+
+## Après `publish.* PASS`
+
+Si une version suivante est déjà décidée et son prompt existe dans la stable, le générateur remet automatiquement la phrase de nouvelle session définie par [`003-NEW_SESSION_PROMPT.md`](003-NEW_SESSION_PROMPT.md), avec les noms réels du ZIP taggé, du rapport post-tag et du prompt versionné.
+
+Si l'horizon reste ouvert, il remet à la place le handoff ou la consigne de revue d'horizon applicable sans inventer de prochaine version.
+
+## Critère de qualité
+
+Le handoff est correct lorsque l'opérateur peut passer du history reçu au commit, au delta suivant ou à la publication sans devoir deviner une commande, un message de commit, un ordre d'application ou un artefact à fournir, tout en conservant explicites les valeurs Git qui ne sont pas encore établies.
--- 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/docs/validation/001-VALIDATION_MATRIX.md
+++ b/docs/validation/001-VALIDATION_MATRIX.md
@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 12 -->
+<!-- version: 13 -->

 # Matrice de validation PGR

@@ -43,6 +43,8 @@ Pour une nouvelle baseline contrôlée, les propriétés sans ordre métier peuv

 [`003-RUST_EXPORT_COMPLETENESS.md`](003-RUST_EXPORT_COMPLETENESS.md) décrit séparément `audit_rust_export_completeness.py`, audit facultatif de façade crate-root. Sa validation ciblée dans PGR est `python3 -B -m unittest discover -s tests -p test_rust_export_completeness.py -v`. L'audit est destiné aux projets Rust qui choisissent explicitement ce contrat ; PGR n'exécute pas ce script sur son propre dépôt comme gate, car il ne constitue pas lui-même un workspace Rust.

+[`004-RUST_CARGO_BASELINE_DRY_RUN.md`](004-RUST_CARGO_BASELINE_DRY_RUN.md) décrit une preuve temporaire de réutilisabilité des skeletons/templates Rust/Cargo. Le mode « nouveau projet » utilise la toolchain officielle dans un répertoire temporaire ; le mode « projet existant » vérifie qu’un mapping d’adoption n’écrase pas les décisions locales classées `KEEP-LOCAL` ou `DEFER`. Cette preuve est sélectionnée lorsque les artefacts Rust/Cargo eux-mêmes changent ou lorsqu’une phase de release doit reconfirmer leur composabilité ; elle n’est pas une cérémonie de chaque delta documentaire.
+
 ## Politique Eclipse actuelle

 Les métadonnées Eclipse spécifiques à une machine restent ignorées, notamment `.project`, `.classpath` et les préférences non partagées.
--- a/docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+++ b/docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
@@ -0,0 +1,100 @@
+<!-- file: docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md -->
+<!-- version: 1 -->
+
+# Dry-run de baseline Rust/Cargo
+
+## Rôle
+
+Ce contrat vérifie que la fondation PGR, le skeleton Rust/Cargo et les cinq templates techniques peuvent être utilisés sans dépendre de KSP ou Games.
+
+Il possède deux modes distincts :
+
+```text
+NEW       nouveau projet : instanciation temporaire réelle des templates
+ADOPTION  projet existant : comparaison et mapping non destructifs
+```
+
+Le dry-run n’est ni un générateur de projet permanent ni une nouvelle architecture applicative. Les répertoires temporaires sont supprimés après la preuve.
+
+## Owners exercés
+
+Le chemin `NEW` compose :
+
+```text
+001-PROJECT_GOVERNANCE_FOUNDATION
+002-RUST_CARGO_WORKSPACE
+500-LANGUAGES
+510-RUST_CARGO
+001-RUST_CARGO_TOOLING
+002-CARGO_MANIFESTS
+```
+
+Le chemin `ADOPTION` ajoute [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et traite `001` / `002` comme checklists de comparaison plutôt que comme recettes de remplacement.
+
+## Mode NEW — nouveau workspace
+
+La preuve temporaire SHOULD :
+
+1. copier les cinq artefacts de `templates/rust-cargo/` dans un répertoire temporaire ;
+2. remplacer `project-name`, `project-core-lib`, le membre workspace et la version d’exemple par des valeurs propres au dry-run ;
+3. créer uniquement le `src/lib.rs` minimal nécessaire à Cargo ;
+4. vérifier qu’aucun placeholder PGR ne reste dans les fichiers adoptés ;
+5. parser les manifests/configurations TOML avec un parseur fiable ;
+6. lorsque Cargo est disponible, exécuter au minimum :
+
+```bash
+cargo metadata --format-version 1 --no-deps
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Le code source temporaire ne devient pas un template PGR. Son seul rôle est de permettre à la toolchain officielle de vérifier les manifests et l’outillage copiés.
+
+## Mode ADOPTION — workspace existant
+
+La preuve d’adoption MUST partir d’un état local qui ne correspond pas byte-for-byte aux templates PGR. Elle doit démontrer au minimum un mapping contenant plusieurs décisions, par exemple :
+
+```text
+510-RUST_CARGO                         ADOPT
+rustfmt.max_width local               KEEP-LOCAL
+configuration d’artefacts PGR         DEFER
+audit de façade strict                DEFER
+```
+
+Le dry-run MUST vérifier que les fichiers classés `KEEP-LOCAL` ou `DEFER` restent inchangés. Une adoption n’est pas prouvée en recopiant les templates puis en déclarant que le projet existant était compatible.
+
+Lorsque la toolchain est disponible, le workspace existant synthétique ou réel SHOULD rester valide avant et après le mapping : `cargo metadata`, `cargo fmt -- --check`, `cargo check` et, lorsque pertinent, `cargo clippy` restent les preuves autoritaires des contrats Cargo/Rust.
+
+## Prévalidation sans Cargo
+
+Un environnement disposant de Python mais pas de Cargo MAY prévalider :
+
+- syntaxe TOML avec `tomllib` ou un parseur équivalent ;
+- résolution des placeholders attendus ;
+- cohérence des liens entre skeletons, templates et owners ;
+- caractère non destructif du mapping d’adoption ;
+- absence de dépendance à KSP/Games dans les artefacts copiables.
+
+Cette prévalidation ne constitue pas un `PASS` de la toolchain. Lorsqu’une tranche exige le mode `NEW` complet, l’absence de Cargo conduit à `BLOCKED` ou à une preuve explicitement incomplète, jamais à un faux succès.
+
+## Critères de sortie
+
+Le dry-run est réussi lorsque :
+
+```text
+NEW
+- templates adaptés sans placeholder résiduel ;
+- TOML valide ;
+- toolchain Rust/Cargo sélectionnée réussie ;
+- aucun artefact temporaire n’entre dans le dépôt PGR.
+
+ADOPTION
+- baseline locale explicitement distincte ;
+- mapping ADOPT / KEEP-LOCAL / OVERRIDE / DEFER valide ;
+- fichiers KEEP-LOCAL / DEFER préservés ;
+- toolchain locale toujours valide lorsque cette preuve est applicable ;
+- aucun historique n’est réécrit.
+```
+
+Le résultat de release reste possédé par le history de la tranche qui exécute cette preuve.
--- a/history/0.1.0/alpha.1.md
+++ b/history/0.1.0/alpha.1.md
@@ -0,0 +1,103 @@
+<!-- file: history/0.1.0/alpha.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-alpha.1` exécutée le `2026-09-25` valide l'audit de reprise depuis `v0.0.5`, le plan de la première baseline PGR réutilisable et le maintien des futurs domaines `0.1.x` comme axes non numérotés. Aucun fix ni REPLAN de `alpha.1` n'est requis.
+
+Cette preuve ferme uniquement le cadrage `alpha.1`. Elle ne matérialise encore ni la nouvelle convention `rel.N`, ni le handoff automatique des commandes Git, ni un profil technologique supplémentaire.
+
+## Baseline et version
+
+La tranche part de la stable taggée `v0.0.5`, dont l'archive autoritaire et le rapport post-tag `publish.001` ont été audités pendant la préparation du delta.
+
+La version contrôlée après application du delta est :
+
+```text
+0.1.0-alpha.1
+```
+
+L'opérateur a confirmé la présence de `deltas/0.1.0/alpha.1.md` et l'absence du présent history pendant la gate. Les révisions attendues ont été retrouvées :
+
+```text
+README.md                                           version 15
+docs/000-README.md                                 version 18
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md   présent et indexé
+```
+
+## Validation opérateur observée
+
+L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `22:08:29`–`22:08:30`.
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.720s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (173 file(s))
+Markdown table audit: clean (8 table(s), 173 file(s))
+Markdown link audit: clean (163 local link(s), 173 file(s))
+```
+
+Le contrôle structurel spécifique a affiché :
+
+```text
+0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered)
+```
+
+Il confirme notamment :
+
+- les `62` couples delta/history des releases `0.0.1` à `0.0.5` ;
+- la conservation de `rel.001` en `FAIL` et `rel.001.fix.1` en `PASS` dans l'historique `0.0.5` ;
+- la présence des profils Rust/Cargo, Java/Maven/Gradle, Android et Tauri ainsi que des skeletons et de l'étude Tauri attendus ;
+- les décisions de cadrage `rel.1`, commit stable final, releases `0.1.x` par domaine, Games avant KSP et maintien des axes Web/Vite/Android/WASM/Tauri/serveur Rust comme horizons non numérotés ;
+- l'absence de réservation prématurée de `0.1.1` dans `ROADMAP.md`.
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.0/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Le scope correspond donc au delta livré et aucun fichier normatif, profil, template, skeleton, script ou history antérieur n'a été modifié par `alpha.1`.
+
+## Revue de cadrage
+
+Les précisions ajoutées pendant la session ne remettent pas en cause le scope validé de `alpha.1` :
+
+- les domaines Web, serveur Rust, Java/Android, WASM et Tauri restent destinés à des releases `0.1.x` séparées ;
+- KSP reste principalement dépendant de la baseline Rust/Cargo déjà mûre et du futur déblocage Tauri ;
+- un futur audit Python simulant uniquement un sous-ensemble statiquement vérifiable des conventions Clippy est conservé comme candidat non prioritaire après les adoptions Games puis KSP ; il ne remplacera pas `cargo clippy` ;
+- les profils de déploiement/exploitation — reverse proxy, bases de données, conteneurs et responsabilités associées — restent un horizon plus lointain, sans numéro de release réservé.
+
+Ces deux derniers horizons n'ont pas été introduits dans les fichiers de `alpha.1`. Ils peuvent être enregistrés dans le plan actif lors d'une tranche ultérieure sans transformer cette gate en échec.
+
+## Transition
+
+Appliquer le présent history puis committer et pousser `0.1.0-alpha.1`.
+
+La tranche suivante est :
+
+```text
+0.1.0-alpha.2
+```
+
+Elle est strictement consacrée à la convention future `rel.N`, à l'abandon du padding `rel.001` pour les nouvelles releases et à la distinction entre commits de clôture échoués et commit final stable `X.Y.Z`. Les anciennes releases restent immuables.
--- a/history/0.1.0/alpha.2.fix.1.md
+++ b/history/0.1.0/alpha.2.fix.1.md
@@ -0,0 +1,92 @@
+<!-- file: history/0.1.0/alpha.2.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.2.fix.1 — correction de la gate `rel.N`
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-alpha.2.fix.1` exécutée le `2026-09-26` valide la correction strictement opérationnelle de la gate `rel.N`. Le `FAIL` de `alpha.2` reste conservé comme vérité historique ; aucun owner normatif de la convention `rel.N` n'a dû être réécrit.
+
+## Baseline opérateur
+
+La tranche `0.1.0-alpha.2` a été clôturée avec son history `FAIL`, puis committée et poussée avant application du fix :
+
+```text
+commit       62f3d25
+message      0.1.0-alpha.2
+push         origin/master PASS
+```
+
+Après application du delta de correction, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.2.fix.1
+history/0.1.0/alpha.2.md                            présent dans HEAD et le workspace
+deltas/0.1.0/alpha.2.md                             présent
+deltas/0.1.0/alpha.2.fix.1.md                       présent
+history/0.1.0/alpha.2.fix.1.md                      absent pendant la gate
+docs/rules/200-GOVERNANCE.md                        version 5
+docs/rules/210-WORKFLOW.md                          version 6
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 3
+```
+
+Le statut `FAIL` de `history/0.1.0/alpha.2.md` a également été retrouvé explicitement.
+
+## Validation opérateur observée
+
+La preuve Python corrigée a terminé proprement :
+
+```text
+0.1.0 alpha.2.fix.1 rel gate audit: clean (failed gate preserved, rel.N content reconfirmed, shell-sensitive assertions safe)
+```
+
+Elle reconfirme notamment :
+
+- `rel.1` et `rel.1.fix.1` comme représentation future sans padding ;
+- la règle du premier `history rel.N[/fix.M] PASS` qui établit réellement la stable ;
+- la conservation de `publish.001` comme identité indépendante ;
+- la présence intacte des quatre artefacts historiques `rel.001*` de `0.0.5` ;
+- les horizons différés concernant le sous-ensemble statique Rust/Clippy et le futur domaine deployment/operations ;
+- l'absence de réservation prématurée de `0.1.1` dans `ROADMAP.md`.
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.715s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (177 file(s))
+Markdown table audit: clean (8 table(s), 177 file(s))
+Markdown link audit: clean (163 local link(s), 177 file(s))
+```
+
+## Contrôles Git
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.2.fix.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Le scope correspond au correctif annoncé. `docs/rules/200-GOVERNANCE.md`, `docs/rules/210-WORKFLOW.md` et le delta historique `alpha.2.md` sont restés inchangés.
+
+## Décision
+
+`0.1.0-alpha.2.fix.1` est `PASS`. Aucun nouveau fix ni REPLAN n'est requis.
+
+La trajectoire normale reprend à :
+
+```text
+0.1.0-alpha.3
+```
+
+Cette tranche formalise la remise automatique des commandes opérateur après chaque history, l'ordre commit/push avant le delta suivant, la clôture stable avec tag et les preuves à fournir pour la vérification post-tag.
--- a/history/0.1.0/alpha.2.md
+++ b/history/0.1.0/alpha.2.md
@@ -0,0 +1,130 @@
+<!-- file: history/0.1.0/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.2 — clôture stable et identité `rel.N`
+
+## Statut
+
+FAIL
+
+La gate opérateur de `0.1.0-alpha.2` exécutée le `2026-09-26` n'a pas atteint un PASS complet. Le contenu normatif de la tranche est présent et les suites Python ainsi que les audits Markdown ont réussi, mais plusieurs commandes `grep -F` prescrites par le delta ont été mal formées pour le shell en raison d'apostrophes littérales dans des motifs entourés de quotes simples. La preuve opérateur contient donc des erreurs de commande et la tranche doit rester `FAIL` jusqu'à correction de sa gate.
+
+Le défaut observé appartient à la validation livrée par `alpha.2`; aucun défaut du contenu `rel.N` n'est établi par les contrôles exécutés.
+
+## Baseline opérateur
+
+La tranche précédente `0.1.0-alpha.1` a été committée et poussée avant application de `alpha.2` :
+
+```text
+commit       c22cf39
+message      0.1.0-alpha.1
+push         origin/master PASS
+```
+
+Après application de `alpha.2`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.2
+history/0.1.0/alpha.1.md                            présent
+deltas/0.1.0/alpha.2.md                             présent
+history/0.1.0/alpha.2.md                            absent pendant la gate
+docs/rules/200-GOVERNANCE.md                        version 5
+docs/rules/210-WORKFLOW.md                          version 6
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 2
+```
+
+## Défaut exact de la gate
+
+Le delta contenait notamment :
+
+```bash
+grep -F 'représentation canonique n'utilise pas de zéro de padding' docs/rules/200-GOVERNANCE.md
+```
+
+L'apostrophe de `n'utilise` ferme la quote simple ouverte avant `représentation`. Le shell poursuit alors l'analyse des lignes suivantes avec un état de quoting incohérent. La transcription opérateur contient notamment :
+
+```text
+bash: publish.001 : commande introuvable
+grep: pas: Aucun fichier ou dossier de ce nom
+grep: zéro: Aucun fichier ou dossier de ce nom
+grep: clôture: Aucun fichier ou dossier de ce nom
+grep: rel.1: Aucun fichier ou dossier de ce nom
+```
+
+Un second motif comportait également une apostrophe littérale :
+
+```bash
+grep -F 'série dédiée au déploiement et à l'exploitation' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Ces erreurs ne peuvent pas être classées comme simples diagnostics attendus : elles proviennent de commandes de validation obligatoires livrées par la tranche. Conformément à la chaîne PGR, une gate prescrite qui n'est pas exécutable proprement rend la tranche `FAIL` même si une preuve ultérieure couvre correctement le fond.
+
+## Preuves de fond réussies
+
+La suite Python globale a exécuté `48` tests et tous ont réussi :
+
+```text
+Ran 48 tests in 0.717s
+
+OK
+```
+
+Les audits Markdown ont affiché :
+
+```text
+Markdown header audit: clean (175 file(s))
+Markdown table audit: clean (8 table(s), 175 file(s))
+Markdown link audit: clean (163 local link(s), 175 file(s))
+```
+
+Le contrôle structurel spécifique de la tranche a également réussi :
+
+```text
+0.1.0 alpha.2 rel identity audit: clean (rel.N unpadded, historical rel.001 preserved, stable commit identity explicit)
+```
+
+Cette preuve confirme notamment que :
+
+- la convention future `rel.N` sans padding est matérialisée ;
+- les artefacts historiques `rel.001*` sont conservés ;
+- l'identité du commit stable est explicitement distinguée de la tranche de clôture ;
+- `publish.001` reste indépendant ;
+- les horizons Clippy statique et deployment/operations restent différés dans le plan.
+
+Le scope Git observé avant ajout du présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.2.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/rules/200-GOVERNANCE.md
+M  docs/rules/210-WORKFLOW.md
+```
+
+## Décision
+
+Aucun REPLAN n'est requis et aucun owner normatif ne doit être réécrit pour corriger cet incident.
+
+La correction reste strictement dans :
+
+```text
+0.1.0-alpha.2.fix.1
+```
+
+Le fix doit :
+
+- conserver intégralement le delta historique `alpha.2.md` ;
+- conserver les contenus actuels de `200-GOVERNANCE.md` et `210-WORKFLOW.md` ;
+- remplacer les assertions shell fragiles par une preuve Python syntaxiquement sûre ;
+- rejouer les `48` tests et les trois audits Markdown ;
+- confirmer à nouveau le scope et la vérité historique avant progression vers `alpha.3`.
+
+## Résultat
+
+`0.1.0-alpha.2` est enregistré `FAIL` pour défaut de gate opérateur, sans défaut normatif établi sur la convention `rel.N`.
+
+La seule transition autorisée est :
+
+```text
+0.1.0-alpha.2.fix.1
+```
--- a/history/0.1.0/alpha.3.fix.1.md
+++ b/history/0.1.0/alpha.3.fix.1.md
@@ -0,0 +1,94 @@
+<!-- file: history/0.1.0/alpha.3.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.3.fix.1 — correction de la gate du handoff opérateur
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-alpha.3.fix.1` exécutée le `2026-09-26` a réussi. Le `FAIL` historique de `alpha.3` est conservé, la syntaxe du contrôle Python a été corrigée sans modifier les owners du handoff, puis le contenu de `210-WORKFLOW.md` et de `006-OPERATOR_COMMAND_HANDOFF.md` a été reconfirmé.
+
+## Baseline opérateur
+
+La tranche `0.1.0-alpha.3` a été clôturée avec son history `FAIL`, puis committée et poussée avant application du fix :
+
+```text
+commit       f374816
+message      0.1.0-alpha.3
+push         origin/master PASS
+```
+
+Après application du correctif, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.3.fix.1
+history/0.1.0/alpha.3.md                            présent dans HEAD et le workspace
+deltas/0.1.0/alpha.3.md                             présent
+deltas/0.1.0/alpha.3.fix.1.md                       présent
+docs/templates/006-OPERATOR_COMMAND_HANDOFF.md      présent
+history/0.1.0/alpha.3.fix.1.md                      absent pendant la gate
+docs/rules/210-WORKFLOW.md                          version 7
+docs/templates/006-OPERATOR_COMMAND_HANDOFF.md      version 1
+docs/000-README.md                                  version 19
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 5
+```
+
+Le statut `FAIL` de `history/0.1.0/alpha.3.md` a été retrouvé explicitement.
+
+## Validation opérateur observée
+
+Le contrôle Python corrigé a terminé proprement :
+
+```text
+0.1.0 alpha.3.fix.1 operator handoff gate: clean (alpha.3 FAIL preserved, workflow/template reconfirmed, Python literals safe)
+```
+
+Il reconfirme notamment :
+
+- le contrat normatif de remise automatique dans `210-WORKFLOW.md` ;
+- l'interdiction d'inventer remote, branche ou politique de tag ;
+- la clôture stable au premier `rel.N[/fix.M]` réellement `PASS` ;
+- la distinction entre objet tag et commit déréférencé ;
+- la production de `publish.*` uniquement à partir de preuves post-publication réellement disponibles ;
+- les blocs du pattern opérateur pour tranche ordinaire, échec + fix, stable, tag et reprise après `publish.* PASS`.
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.688s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (182 file(s))
+Markdown table audit: clean (8 table(s), 182 file(s))
+Markdown link audit: clean (167 local link(s), 182 file(s))
+```
+
+## Contrôles Git
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.3.fix.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Le scope correspond au correctif annoncé. `docs/rules/210-WORKFLOW.md`, `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`, `docs/000-README.md` et le delta historique `alpha.3.md` sont restés inchangés.
+
+## Décision
+
+`0.1.0-alpha.3.fix.1` est `PASS`. Aucun nouveau fix ni REPLAN n'est requis.
+
+La trajectoire normale reprend à :
+
+```text
+0.1.0-alpha.4
+```
+
+Cette tranche formalise l'adoption proportionnée de PGR par un projet existant, distincte de l'instanciation d'un nouveau projet et sans migration concrète de Games ou KSP dans `0.1.0`.
--- a/history/0.1.0/alpha.3.md
+++ b/history/0.1.0/alpha.3.md
@@ -0,0 +1,115 @@
+<!-- file: history/0.1.0/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.3 — handoff automatique des commandes opérateur
+
+## Statut
+
+FAIL
+
+La gate opérateur de `0.1.0-alpha.3` exécutée le `2026-09-26` n'a pas atteint un PASS complet. Le contenu de workflow et le nouveau pattern de handoff ont été appliqués, les `48` tests ont réussi et les trois audits Markdown sont propres, mais le contrôle Python obligatoire livré par le delta contient une chaîne littérale invalide : l'apostrophe de `d'une` ferme prématurément une chaîne entourée de quotes simples.
+
+Le défaut appartient donc à la gate de validation de `alpha.3`. Aucun défaut normatif de `210-WORKFLOW.md` ni de `006-OPERATOR_COMMAND_HANDOFF.md` n'est établi par les preuves opérateur disponibles.
+
+## Baseline opérateur
+
+La tranche précédente `0.1.0-alpha.2.fix.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `alpha.3` :
+
+```text
+commit       3230356
+message      0.1.0-alpha.2.fix.1
+push         origin/master PASS
+```
+
+Après application de `alpha.3`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.3
+history/0.1.0/alpha.2.fix.1.md                      présent
+deltas/0.1.0/alpha.3.md                             présent
+docs/templates/006-OPERATOR_COMMAND_HANDOFF.md      présent
+history/0.1.0/alpha.3.md                            absent pendant la gate
+docs/rules/210-WORKFLOW.md                          version 7
+docs/000-README.md                                  version 19
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 4
+```
+
+## Défaut exact de la gate
+
+Le delta contenait dans son bloc Python :
+
+```python
+for phrase in (
+    '## Fermeture d'une tranche non stable',
+    ...
+):
+    assert phrase in template, phrase
+```
+
+L'apostrophe de `d'une` termine la chaîne Python avant `une tranche non stable`. L'interpréteur a donc arrêté le contrôle spécifique avec :
+
+```text
+File "<stdin>", line 24
+    '## Fermeture d'une tranche non stable',
+                                     ^
+SyntaxError: unterminated string literal (detected at line 24)
+```
+
+La gate spécifique n'a donc pas pu produire son message final `clean`. Ce défaut est analogue à celui déjà rencontré sur `alpha.2`, mais il se situe cette fois dans une chaîne Python et non dans le quoting shell d'un `grep`.
+
+## Preuves réussies malgré le défaut
+
+La suite Python globale a exécuté `48` tests et tous ont réussi :
+
+```text
+Ran 48 tests in 0.698s
+
+OK
+```
+
+Les audits Markdown ont affiché :
+
+```text
+Markdown header audit: clean (180 file(s))
+Markdown table audit: clean (8 table(s), 180 file(s))
+Markdown link audit: clean (167 local link(s), 180 file(s))
+```
+
+Le scope Git observé avant ajout du présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.3.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/rules/210-WORKFLOW.md
+A  docs/templates/006-OPERATOR_COMMAND_HANDOFF.md
+```
+
+Ce scope correspond aux six fichiers annoncés par `alpha.3`.
+
+## Décision
+
+Aucun REPLAN n'est requis. Le correctif doit rester strictement limité à la gate de `alpha.3` :
+
+```text
+0.1.0-alpha.3.fix.1
+```
+
+Le fix doit :
+
+- conserver intégralement le delta historique `alpha.3.md` ;
+- conserver `docs/rules/210-WORKFLOW.md`, `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md` et `docs/000-README.md` inchangés ;
+- remplacer uniquement les littéraux Python fragiles de la validation par une forme syntaxiquement sûre ;
+- reconfirmer le history `alpha.3` en `FAIL`, le contenu du workflow et du template, les `48` tests et les trois audits Markdown ;
+- vérifier que le scope du fix reste borné à `VERSION`, au plan actif et au nouveau delta de correction.
+
+## Résultat
+
+`0.1.0-alpha.3` est enregistré `FAIL` pour défaut de syntaxe dans sa gate opérateur, sans défaut normatif établi sur le handoff automatique des commandes.
+
+La seule transition autorisée est :
+
+```text
+0.1.0-alpha.3.fix.1
+```
--- 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.
--- a/history/0.1.0/alpha.5.md
+++ b/history/0.1.0/alpha.5.md
@@ -0,0 +1,148 @@
+<!-- file: history/0.1.0/alpha.5.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-alpha.5 — baseline Rust/Cargo réutilisable et dry-run
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-alpha.5` exécutée le `2026-09-26` a réussi. Les deux chemins définis par `004-RUST_CARGO_BASELINE_DRY_RUN.md` ont été exercés avec la toolchain Cargo réelle : instanciation d'un nouveau workspace à partir des templates PGR et adoption non destructive d'un workspace Rust existant synthétique.
+
+## Baseline opérateur
+
+La tranche `0.1.0-alpha.4` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `alpha.5` :
+
+```text
+commit       e4b5992
+message      0.1.0-alpha.4
+push         origin/master PASS
+```
+
+Après application du delta `alpha.5`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-alpha.5
+history/0.1.0/alpha.4.md                            présent dans HEAD et le workspace
+deltas/0.1.0/alpha.5.md                             présent
+docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md  présent
+history/0.1.0/alpha.5.md                            absent pendant la gate
+docs/000-README.md                                  version 21
+docs/skeletons/000-README.md                        version 5
+docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md version 4
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md          version 6
+docs/templates/001-RUST_CARGO_TOOLING.md            version 4
+docs/templates/002-CARGO_MANIFESTS.md               version 4
+docs/validation/001-VALIDATION_MATRIX.md             version 13
+docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md   version 1
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md     version 7
+```
+
+Le history précédent a été retrouvé avec statut `PASS`.
+
+## Validation structurelle
+
+Le contrôle structurel et TOML a terminé proprement :
+
+```text
+0.1.0 alpha.5 structural/TOML audit: clean (NEW and ADOPTION paths explicit, templates parse, external corpora not required)
+```
+
+Il confirme notamment :
+
+- le lien des skeletons `001` et `002` vers le contrat d'adoption `230-ADOPTION.md` ;
+- l'existence des deux chemins `NEW` et `ADOPTION` ;
+- la présence de `KEEP-LOCAL` et `DEFER` dans les guides applicables ;
+- le parsing TOML des cinq templates Rust/Cargo ;
+- l'absence de dépendance obligatoire à Games ou KSP pour cette preuve ;
+- l'absence de réservation anticipée d'une future `0.1.1` avant la revue d'horizon.
+
+## Dry-run `NEW`
+
+La gate a matérialisé les templates dans un répertoire temporaire, résolu les placeholders, créé uniquement le source Rust minimal nécessaire au test, puis exécuté la toolchain officielle.
+
+Résultat observé :
+
+```text
+cargo metadata --format-version 1 --no-deps   PASS
+cargo fmt --all -- --check                    PASS
+cargo check --workspace                       PASS
+cargo clippy --workspace --all-targets --all-features -- -D warnings   PASS
+
+0.1.0 alpha.5 NEW dry-run: clean (temporary templates accepted by Cargo/rustfmt/Clippy)
+```
+
+La crate temporaire `pgr-dryrun-core-lib` en version `9.9.9` a été reconnue par Cargo et les commandes `check` / `clippy` ont terminé sans diagnostic bloquant.
+
+## Dry-run `ADOPTION`
+
+La gate a créé un workspace Rust synthétique préexistant distinct des templates PGR, avec notamment `rustfmt.toml` conservant `max_width = 120`.
+
+Le mapping exercé contenait :
+
+```text
+510-RUST_CARGO                      ADOPT
+rustfmt.max_width=120               KEEP-LOCAL
+PGR external artifact configuration DEFER
+strict crate-root export audit      DEFER
+```
+
+Les mêmes contrôles Cargo ont réussi et les hashes des fichiers protégés avant/après sont restés identiques.
+
+Résultat observé :
+
+```text
+0.1.0 alpha.5 ADOPTION dry-run: clean (local KEEP-LOCAL/DEFER choices preserved, workspace remains valid)
+```
+
+La preuve établit donc qu'une adoption ne nécessite pas de recopier aveuglément les templates ni d'écraser les décisions locales légitimes.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.726s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (189 file(s))
+Markdown table audit: clean (8 table(s), 189 file(s))
+Markdown link audit: clean (189 local link(s), 189 file(s))
+```
+
+## Contrôles Git
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.0/alpha.5.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/skeletons/000-README.md
+M  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+M  docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+M  docs/templates/001-RUST_CARGO_TOOLING.md
+M  docs/templates/002-CARGO_MANIFESTS.md
+M  docs/validation/001-VALIDATION_MATRIX.md
+A  docs/validation/004-RUST_CARGO_BASELINE_DRY_RUN.md
+```
+
+Le scope correspond exactement au delta annoncé. Les templates techniques sous `templates/rust-cargo/` eux-mêmes sont restés inchangés.
+
+## Décision
+
+`0.1.0-alpha.5` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+La trajectoire quitte les alphas et reprend à :
+
+```text
+0.1.0-beta.1
+```
+
+`beta.1` réconcilie la baseline durable, exécute la revue d'horizon obligatoire et engage uniquement les prochaines releases `0.1.x` dont le domaine, l'ordre et les prérequis sont suffisamment décidés avant RC.
--- a/history/0.1.0/beta.1.md
+++ b/history/0.1.0/beta.1.md
@@ -0,0 +1,110 @@
+<!-- file: history/0.1.0/beta.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-beta.1 — réconciliation finale et revue d'horizon
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-beta.1` exécutée le `2026-09-26` a réussi. Elle valide la réconciliation de la baseline `0.1.0`, la revue d'horizon obligatoire, la roadmap engagée `0.1.1` à `0.1.7` et le prompt de reprise `007` vers la fondation frontend Web.
+
+## Baseline opérateur
+
+La tranche `0.1.0-alpha.5` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `beta.1` :
+
+```text
+commit       a65a183
+message      0.1.0-alpha.5
+push         origin/master PASS
+```
+
+Après application du delta `beta.1`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-beta.1
+history/0.1.0/alpha.5.md                            présent dans HEAD et le workspace
+deltas/0.1.0/beta.1.md                              présent
+docs/studies/003-V0_1_0_HORIZON_REVIEW.md          présent
+prompts/007-V0_1_1_START_PROMPT.md                  présent
+history/0.1.0/beta.1.md                             absent pendant la gate
+ROADMAP.md                                           version 9
+docs/000-README.md                                  version 22
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 8
+docs/studies/000-README.md                          version 3
+docs/studies/003-V0_1_0_HORIZON_REVIEW.md          version 1
+prompts/007-V0_1_1_START_PROMPT.md                  version 1
+```
+
+Le history `alpha.5` a été retrouvé avec statut `PASS`.
+
+## Revue d'horizon
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.0 beta.1 horizon review audit: clean (0.1.1..0.1.7 engaged, Tauri conditional, deferred domains remain unnumbered)
+```
+
+La roadmap engage désormais, dans cet ordre :
+
+```text
+0.1.1  fondation frontend Web
+0.1.2  Java / Gradle
+0.1.3  Android
+0.1.4  Tauri sous condition de readiness Web
+0.1.5  adoption sasedev-games
+0.1.6  adoption khadhroony-solana-project
+0.1.7  audits Rust/Clippy statiques Python-only
+```
+
+La gate confirme simultanément qu'aucune `0.1.8` n'est réservée, que WASM et le serveur Web Rust/Actix ou alternative restent sans numéro et que le domaine `deployment & operations` demeure un horizon ultérieur sans réservation précise.
+
+La décision `DEFER` du skeleton Tauri reste applicable pendant `0.1.0`. Le prompt `007` prépare `0.1.1` mais n'autorise ni migration Games/KSP, ni Tauri, ni WASM, ni serveur Rust dans cette release Web.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.762s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (193 file(s))
+Markdown table audit: clean (8 table(s), 193 file(s))
+Markdown link audit: clean (193 local link(s), 193 file(s))
+```
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.0/beta.1.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/003-V0_1_0_HORIZON_REVIEW.md
+A  prompts/007-V0_1_1_START_PROMPT.md
+```
+
+Le scope correspond exactement au delta annoncé. Aucun profil technique, template Rust/Cargo, skeleton ou script d'audit n'a été modifié par `beta.1`.
+
+## Décision
+
+`0.1.0-beta.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+La tranche suivante est :
+
+```text
+0.1.0-rc.1
+```
+
+La RC gèle le scope, produit l'entrée candidate du `CHANGELOG`, rejoue le release gate complet applicable, vérifie le handoff opérateur et le prompt `007`, puis prépare la première promotion stable utilisant la convention `rel.1`.
--- a/history/0.1.0/rc.1.md
+++ b/history/0.1.0/rc.1.md
@@ -0,0 +1,119 @@
+<!-- file: history/0.1.0/rc.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-rc.1 — release candidate
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-rc.1` exécutée le `2026-09-26` a réussi. Elle confirme le scope gelé de la première baseline PGR réutilisable, l'intégrité des histories antérieurs, le `CHANGELOG` candidat, la trajectoire `0.1.x`, le prompt `007` et les deux dry-runs Rust/Cargo avec la toolchain réelle.
+
+## Baseline opérateur
+
+La tranche `0.1.0-beta.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rc.1` :
+
+```text
+commit       5393257
+message      0.1.0-beta.1
+push         origin/master PASS
+```
+
+Après application du delta `rc.1`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0-rc.1
+history/0.1.0/beta.1.md                             présent dans HEAD et le workspace
+deltas/0.1.0/rc.1.md                                présent
+prompts/007-V0_1_1_START_PROMPT.md                  présent
+history/0.1.0/rc.1.md                               absent pendant la gate
+CHANGELOG.md                                         version 10
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 9
+ROADMAP.md                                           version 9
+prompts/007-V0_1_1_START_PROMPT.md                  version 1
+```
+
+Le history `beta.1` a été retrouvé avec statut `PASS` et le `CHANGELOG` contient l'entrée `## 0.1.0 (candidate)`.
+
+## Gate d'intégration
+
+Le contrôle d'intégration a affiché :
+
+```text
+0.1.0 rc.1 integration audit: clean (8 prior histories, frozen reusable baseline, candidate changelog, horizon and prompt 007 verified)
+```
+
+Il a vérifié les huit histories antérieurs avec leurs statuts réels :
+
+```text
+alpha.1         PASS
+alpha.2         FAIL
+alpha.2.fix.1   PASS
+alpha.3         FAIL
+alpha.3.fix.1   PASS
+alpha.4         PASS
+alpha.5         PASS
+beta.1          PASS
+```
+
+La gate reconfirme également le contrat `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, la convention `rel.N` sans padding, le commit stable final `X.Y.Z`, le handoff `publish.*`, la roadmap `0.1.1` à `0.1.7`, l'absence de `0.1.8` et la préparation du prompt `007`.
+
+## Dry-runs Rust/Cargo de release
+
+La toolchain Cargo réelle a exercé les deux chemins de la baseline :
+
+```text
+NEW       cargo metadata / fmt / check / clippy -D warnings   PASS
+ADOPTION  cargo metadata / fmt / check / clippy -D warnings   PASS
+```
+
+Résultat observé :
+
+```text
+0.1.0 rc.1 Rust/Cargo release dry-runs: clean (NEW and ADOPTION accepted by Cargo/rustfmt/Clippy)
+```
+
+Le chemin `ADOPTION` conserve le principe de non-écrasement des choix locaux protégés.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.702s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (195 file(s))
+Markdown table audit: clean (8 table(s), 195 file(s))
+Markdown link audit: clean (193 local link(s), 195 file(s))
+```
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.0/rc.1.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Le scope correspond exactement au delta annoncé. Aucun owner, profil, template, skeleton ou script technique n'a été modifié pendant la RC.
+
+## Décision
+
+`0.1.0-rc.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+La tranche suivante est la promotion stable pré-tag :
+
+```text
+0.1.0-rel.1
+```
+
+`rel.1` est la première utilisation réelle de la convention sans padding. Si sa gate obtient `PASS`, son history sera inclus dans le commit stable nommé `0.1.0`, avant création et publication du tag `v0.1.0`.
--- a/history/0.1.0/rel.1.md
+++ b/history/0.1.0/rel.1.md
@@ -0,0 +1,141 @@
+<!-- file: history/0.1.0/rel.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.0-rel.1 — promotion stable pré-tag
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.0-rel.1` exécutée le `2026-09-26` a réussi. Elle confirme la promotion mécanique de la release candidate vers la stable `0.1.0`, la cohérence complète des histories antérieurs, la présentation stable du dépôt, les tests Python et les audits documentaires avant création du tag.
+
+## Baseline opérateur
+
+La tranche `0.1.0-rc.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rel.1` :
+
+```text
+commit       d5e1fc4
+message      0.1.0-rc.1
+push         origin/master PASS
+```
+
+Après application du delta `rel.1`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                             0.1.0
+history/0.1.0/rc.1.md                               présent dans HEAD et le workspace
+deltas/0.1.0/rel.1.md                               présent
+prompts/007-V0_1_1_START_PROMPT.md                  présent
+history/0.1.0/rel.1.md                              absent pendant la gate
+README.md                                            version 16
+ROADMAP.md                                           version 10
+CHANGELOG.md                                         version 11
+docs/000-README.md                                  version 23
+docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md    version 10
+```
+
+Le history `rc.1` a été retrouvé avec statut `PASS`.
+
+La présentation stable est établie :
+
+```text
+ROADMAP.md     0.1.0 marqué terminé
+CHANGELOG.md   entrée `## 0.1.0`
+README.md      première baseline réutilisable stable
+docs index     plan 006 classé historique
+```
+
+## Gate stable pré-tag
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.0 rel.1 stable gate audit: clean (9 prior histories, rel.1 pending, stable presentation and post-tag handoff coherent)
+```
+
+Il a vérifié les neuf histories antérieurs avec leurs statuts réels :
+
+```text
+alpha.1         PASS
+alpha.2         FAIL
+alpha.2.fix.1   PASS
+alpha.3         FAIL
+alpha.3.fix.1   PASS
+alpha.4         PASS
+alpha.5         PASS
+beta.1          PASS
+rc.1            PASS
+```
+
+Avant application du présent history, `rel.1.md` est la seule tranche `0.1.0` possédant un delta sans history.
+
+La gate reconfirme également :
+
+- `0.1.0` terminé dans la roadmap ;
+- `0.1.1` à `0.1.7` engagés sans réservation de `0.1.8` ;
+- le `CHANGELOG` stable sans suffixe `(candidate)` ;
+- l'absence de la coquille `produit produit` ;
+- le plan `006` classé historique ;
+- le prompt `007` préparé pour démarrer `0.1.1` depuis le tag `v0.1.0` et le rapport `publish.001` ;
+- la convention `rel.N` et le commit stable final `X.Y.Z`.
+
+## Preuve Rust/Cargo
+
+Les deux dry-runs Rust/Cargo de release ont obtenu `PASS` pendant `0.1.0-rc.1` avec la toolchain réelle :
+
+```text
+NEW       cargo metadata / fmt / check / clippy -D warnings   PASS
+ADOPTION  cargo metadata / fmt / check / clippy -D warnings   PASS
+```
+
+Ils n'ont pas été rejoués pendant `rel.1`, car la promotion stable ne modifie aucun owner, template, skeleton, script ou artefact Rust/Cargo depuis la RC. Le présent history ne prétend donc pas à une nouvelle exécution de ces dry-runs.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.757s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (197 file(s))
+Markdown table audit: clean (8 table(s), 197 file(s))
+Markdown link audit: clean (193 local link(s), 197 file(s))
+```
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.0/rel.1.md
+M  docs/000-README.md
+M  docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
+```
+
+Le scope correspond exactement à la promotion stable annoncée. Aucun owner, profil, template, skeleton ou script technique n'a été modifié.
+
+## Décision
+
+`0.1.0-rel.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+Conformément à la convention stable désormais normative, le présent history doit être inclus dans le commit final nommé exactement :
+
+```text
+0.1.0
+```
+
+Le commit stable sera ensuite poussé sur la branche établie, puis le tag annoté `v0.1.0` sera créé et publié.
+
+Le rapport `pgr-0.1.0-publish.001-report.md` ne pourra être produit qu'après réception des preuves post-publication réelles : identité du commit stable, propreté du workspace, objet et cible déréférencée du tag local, références distantes du tag et archive ZIP téléchargée depuis le tag Gitea.
--- a/prompts/007-V0_1_1_START_PROMPT.md
+++ b/prompts/007-V0_1_1_START_PROMPT.md
@@ -0,0 +1,77 @@
+<!-- file: prompts/007-V0_1_1_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.1.1 — fondation frontend Web
+
+## Baseline et cible
+
+Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline attendue au démarrage effectif de `0.1.1` est l'archive source téléchargée depuis le tag Gitea `v0.1.0`, accompagnée du rapport post-tag `pgr-0.1.0-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
+
+Version cible : `0.1.1`. Première tranche attendue : `0.1.1-alpha.1`.
+
+Le corpus principal attendu pour instruire le besoin Web est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste :
+
+```text
+games-v0.3.6.zip  ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+```
+
+Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
+
+## Mission
+
+Créer la première fondation frontend Web contrôlée de PGR à partir de besoins réellement exercés, principalement dans Games, sans importer automatiquement les choix locaux du corpus.
+
+`alpha.1` MUST commencer par :
+
+1. auditer indépendamment la stable `v0.1.0` et son rapport post-tag lorsqu'il est fourni ;
+2. auditer le corpus Games réellement fourni et identifier les responsabilités Web exercées ;
+3. relire `docs/studies/003-V0_1_0_HORIZON_REVIEW.md` et `docs/studies/002-TAURI_SKELETON_DECISION.md` ;
+4. créer le plan `0.1.1` avant toute normalisation importante.
+
+## Scope de domaine attendu
+
+La release doit instruire ensemble les responsabilités nécessaires à un frontend Web contrôlé :
+
+- TypeScript et configuration applicable ;
+- Vite, dev server et contrat de build outputs ;
+- Sass/CSS, sources et artefacts générés ;
+- package manager, manifest et lockfile sans imposer arbitrairement npm ;
+- séparation entre validation frontend et validation du host ;
+- templates, skeletons et audits read-only seulement lorsqu'ils apportent une preuve générique réelle.
+
+La release peut créer plusieurs owners si les responsabilités l'exigent, mais reste une seule release de domaine Web frontend.
+
+## Hors scope
+
+`0.1.1` MUST NOT :
+
+- créer le skeleton Tauri contrôlé ;
+- intégrer WASM au host ou créer un profil WASM par simple proximité ;
+- normaliser Actix Web ou un autre serveur Rust sans corpus d'implémentation suffisant ;
+- migrer Games vers PGR ;
+- migrer KSP vers PGR ;
+- réécrire le profil Java/Gradle ou Android, qui possèdent leurs releases dédiées `0.1.2` et `0.1.3` ;
+- traiter les sujets deployment/operations de l'horizon futur.
+
+## Relation avec Tauri
+
+Le skeleton Tauri reste `DEFER` pendant cette release. `0.1.1` doit néanmoins produire les owners Web suffisamment explicites pour que `0.1.4` puisse réexaminer objectivement les conditions de sortie de `002-TAURI_SKELETON_DECISION.md`.
+
+La réussite de `0.1.1` ne vaut pas automatiquement levée du `DEFER` Tauri.
+
+## Principes
+
+- Partir des faits observés dans le corpus, pas d'un catalogue théorique du Web moderne.
+- Un outil ou package manager n'est pas rendu obligatoire parce qu'il est présent dans Games.
+- Les sorties générées doivent avoir un owner clair et une politique explicite de versionnement/ignorance.
+- Les audits Python restent monotâches et read-only ; ils ne remplacent ni TypeScript, ni Vite, ni Sass, ni le package manager.
+- Conserver la distinction `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` pour préparer l'adoption Games ultérieure.
+- Ne pas réserver de nouvelles releases au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée.
+
+## Workflow
+
+Suivre `RULES.md`, `docs/rules/210-WORKFLOW.md`, `docs/rules/230-ADOPTION.md` et `docs/rules/400-VALIDATION.md`.
+
+La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
Author	SHA1	Message	Date
SinuS Von SifriduS	2ed8742f3b	0.1.0	2026-09-26 23:31:54 +02:00
SinuS Von SifriduS	d5e1fc4300	0.1.0-rc.1	2026-09-26 23:26:23 +02:00
SinuS Von SifriduS	5393257d93	0.1.0-beta.1	2026-09-26 23:10:02 +02:00
SinuS Von SifriduS	a65a183ee4	0.1.0-alpha.5	2026-09-26 20:33:53 +02:00
SinuS Von SifriduS	e4b5992266	0.1.0-alpha.4	2026-09-26 19:31:22 +02:00
SinuS Von SifriduS	351025b4f2	0.1.0-alpha.3.fix.1	2026-09-26 19:19:20 +02:00
SinuS Von SifriduS	f37481627a	0.1.0-alpha.3	2026-09-26 19:06:59 +02:00
SinuS Von SifriduS	3230356cd6	0.1.0-alpha.2.fix.1	2026-09-26 19:00:32 +02:00
SinuS Von SifriduS	62f3d252d8	0.1.0-alpha.2	2026-09-26 17:33:23 +02:00
SinuS Von SifriduS	c22cf39ba9	0.1.0-alpha.1	2026-09-26 17:25:10 +02:00
@@ -1 +1 @@
 .0.5
 .1.0