0.1.0-alpha.5

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 20 -->
+<!-- version: 21 -->
 
 # Documentation PGR
 
@@ -26,6 +26,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 - [`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.
 
 ## Points d'entrée de 0.0.5
 

docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Plan 0.1.0 — première baseline PGR réutilisable
 
@@ -205,19 +205,26 @@ La validation a exécuté `48/48` tests et les trois audits Markdown sans diagno
 
 ### alpha.4 — adoption d'un projet existant
 
-Statut opérateur : **à valider**.
+Statut opérateur : **PASS**.
 
-Formaliser une méthode courte d'adoption PGR pour un dépôt existant : audit de la baseline réelle, mapping des owners applicables, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, migration progressive et interdiction de réécrire l'historique uniquement pour le rendre rétroactivement conforme.
+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.
 
-Le nouvel owner `230-ADOPTION.md` doit distinguer explicitement adoption et instanciation par skeleton. Le pattern `007-EXISTING_PROJECT_ADOPTION.md` doit fournir une forme réutilisable sans devenir un manifest obligatoire.
-
-Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet ni migrer effectivement ces dépôts dans `0.1.0`.
+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
 
-Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Effectuer un dry-run documentaire/structurel d'instanciation et d'adoption afin de vérifier qu'un nouveau projet Rust et un projet Rust existant peuvent sélectionner les owners utiles sans dépendre de KSP/Games.
+Statut opérateur : **à valider**.
 
-Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche.
+Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Le contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` distingue explicitement :
+
+```text
+NEW       instanciation temporaire réelle des templates avec Cargo
+ADOPTION  mapping non destructif d’un workspace existant
+```
+
+La gate doit exercer le mode `NEW` avec `cargo metadata`, `cargo fmt`, `cargo check` et `cargo clippy`, puis exercer le mode `ADOPTION` sur une baseline synthétique différente des templates et prouver que les décisions `KEEP-LOCAL` / `DEFER` ne sont pas écrasées.
+
+Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche. Games et KSP ne sont pas utilisés comme fixtures du dry-run.
 
 ### beta.1 — réconciliation finale et revue d'horizon
 

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).

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

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.
 

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 :

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.

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.

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.