0.0.4

CHANGELOG.md

@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 5 -->
+<!-- version: 7 -->
 
 # Changelog Project Governance Rules
 
@@ -7,6 +7,14 @@ 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.0.4
+
+- définit un contrat transversal de skeleton specifications pour sélectionner et composer règles, profils, templates, décisions destinataire, overrides et validation sans dupliquer les propriétaires normatifs ;
+- ajoute une fondation composable de gouvernance locale pour initialiser version, documentation minimale, workflow retenu et validation proportionnée d'un projet utilisant PGR ;
+- ajoute une spécialisation Rust/Cargo workspace composant la fondation avec les profils `500 + 510` et les cinq templates Rust/Cargo existants ;
+- explicite les décisions à adapter avant instanciation, notamment version, édition/toolchain, membres, métadonnées, dépendances/features, `Cargo.lock`, lints, chemins d'artefacts et audits facultatifs ;
+- conserve Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles insuffisamment matérialisées comme domaines différés plutôt que créer des skeletons prématurés.
+
 ## 0.0.3
 
 - fournit cinq fichiers modèles Rust/Cargo : `rustfmt.toml`, `clippy.toml`, `.cargo/config.toml`, un manifest workspace et un manifest de crate membre, avec instructions d'adaptation ;

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 6 -->
+<!-- version: 11 -->
 
 # Project Governance Rules
 
@@ -13,7 +13,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
 
 PGR est actuellement en phase de fondation `0.0.x`.
 
-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 série `0.0.x` se poursuit avec les spécifications de skeletons prévues pour `0.0.4`.
+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. Les autres spécialisations technologiques restent différées tant que leurs pièces requises manquent.
 
 ## Entrées principales
 
@@ -27,6 +27,10 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
 - [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan historique de fondation `0.0.1` ;
 - [`docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md`](docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md) — plan historique des premiers profils `0.0.2` ;
 - [`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/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 ;
+- [`docs/skeletons/002-RUST_CARGO_WORKSPACE.md`](docs/skeletons/002-RUST_CARGO_WORKSPACE.md) — specialization composable pour un workspace Rust/Cargo gouverné ;
 - [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
 
 ## Langue et nomenclature

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Roadmap Project Governance Rules
 
@@ -12,7 +12,7 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
 - `(x) 0.0.1` — fondation normative et documentaire : gouvernance, lifecycle des releases, rôles documentaires, workflow delta/history/handoff et validation proportionnée ;
 - `(x) 0.0.2` — premiers profils de règles réutilisables : Rust/Cargo, Java/Maven/Gradle et Android, avec modèle de composition et audits Markdown initiaux ;
 - `(x) 0.0.3` — templates techniques initiaux et premiers patterns d'audit réutilisables issus de besoins réels ;
-- `( ) 0.0.4` — spécifications Markdown de skeletons et règles de composition des profils/templates ;
+- `(x) 0.0.4` — spécifications Markdown de skeletons et règles de composition des profils/templates ;
 - `( ) 0.0.5` — réconciliation réelle de PGR avec `khadhroony-solana-project` et `sasedev-games`.
 
 ## Première baseline réutilisable

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Index normatif Project Governance Rules
 
@@ -76,6 +76,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/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.

VERSION

@@ -1 +1 @@
-0.0.3
+0.0.4

deltas/0.0.4/alpha.1.md

@@ -0,0 +1,150 @@
+<!-- file: deltas/0.0.4/alpha.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-alpha.1 — audit de baseline et cadrage des skeletons
+
+## Baseline et version
+
+Baseline : archive source fournie `pgr-v0.0.3.zip`, déclarée téléchargée depuis le tag Gitea `v0.0.3`, accompagnée du rapport externe `pgr-0.0.3-publish.001-report.md` avec statut `PASS`.
+
+SHA-256 vérifié de l'archive :
+
+```text
+517fb46ada098fdc221ae53a8ff4b409b81e0244ec5ce4d0e6fca0c3da61b866
+```
+
+Le rapport post-tag annonce le même hash et reste extérieur à la stable. L'archive sans `.git` est contrôlée par son contenu ; elle n'est pas utilisée comme preuve autonome du commit ou de la référence distante du tag.
+
+Version avant application :
+
+```text
+0.0.3
+```
+
+Version après application :
+
+```text
+0.0.4-alpha.1
+```
+
+## Objet
+
+Exécuter la gate de cadrage imposée par `prompts/004-V0_0_4_START_PROMPT.md` avant toute matérialisation importante : vérifier la stable, les règles `200` à `610`, la gouvernance documentaire, les templates et audits existants, la chaîne delta/history et les limites annoncées ; déterminer ensuite quels skeletons disposent déjà d'entrées suffisantes et planifier les tranches de `0.0.4`.
+
+Le résultat détaillé de cette revue et le découpage prévisionnel sont consignés dans `docs/plans/004-V0_0_4_SKELETONS_PLAN.md`. Aucun défaut bloquant de `0.0.3` n'impose une correction rétroactive avant ce cadrage.
+
+Le plan retient comme premières cibles la fondation composable d'un projet gouverné PGR puis un skeleton Rust/Cargo workspace. Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles sans pièces suffisantes restent différés.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+```
+
+ADD :
+
+```text
+docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+deltas/0.0.4/alpha.1.md
+```
+
+DELETE : aucun.
+
+L'archive delta contient uniquement ces cinq fichiers complets avec leurs chemins relatifs. Aucun history, skeleton concret, nouvelle règle, template technique, script ou manifest de suppression n'appartient à `alpha.1`.
+
+`README.md` et `docs/000-README.md` sont des documents vivants : ils ajoutent le plan actif comme point d'entrée. `ROADMAP.md` annonce déjà `0.0.4` comme planifiée et `CHANGELOG.md` reste limité aux releases publiées ; ils n'ont pas besoin d'une modification cérémonielle dans cette tranche.
+
+## Validation opérateur
+
+Après application sur le commit stable `0.0.3`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-alpha.1'
+test -f docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+test -f deltas/0.0.4/alpha.1.md
+test ! -e history/0.0.4/alpha.1.md
+
+grep -Fx '<!-- version: 7 -->' README.md
+grep -Fx '<!-- version: 5 -->' docs/000-README.md
+grep -F '004-V0_0_4_SKELETONS_PLAN.md' README.md
+grep -F '004-V0_0_4_SKELETONS_PLAN.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
+import tomllib
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+expected_counts = {'0.0.1': 12, '0.0.2': 12, '0.0.3': 10}
+for release, expected in expected_counts.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) == expected, (release, len(deltas))
+    assert deltas == histories, (release, sorted(deltas ^ histories))
+
+for path in Path('history/0.0.3').glob('*.md'):
+    text = path.read_text(encoding='utf-8')
+    assert re.search(r'## Statut\s+PASS\s', text), path
+
+for path in (
+    Path('scripts/audit_rust_blank_lines.py'),
+    Path('scripts/audit_rust_const_blocks.py'),
+    Path('scripts/_rust_audit_common.py'),
+):
+    assert path.is_file(), path
+
+print('Baseline structural audit: clean (34 prior delta/history pairs, 10/10 histories 0.0.3 PASS, 5 TOML parsed)')
+PY
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/plans/004-V0_0_4_SKELETONS_PLAN.md deltas/0.0.4/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.0.4/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+La vérification du ZIP et du rapport post-tag appartient à l'intake de cette tranche et a été utilisée pour préparer le plan. L'opérateur confirme également que les fichiers fournis sont bien ceux téléchargés pour la reprise, que le hash de l'archive concorde avec le rapport, que le rapport est `PASS` et qu'il n'est pas copié dans le dépôt.
+
+La revue opérateur doit confirmer que le plan ne transforme pas une prévision en règle active, que les valeurs Rust/Cargo d'exemple restent adaptables et que les domaines différés ne sont pas matérialisés par anticipation.
+
+## Transition
+
+### PASS
+
+Rédiger et livrer séparément `history/0.0.4/alpha.1.md` avec les résultats réellement observés ; l'appliquer et committer la tranche. Préparer seulement ensuite `0.0.4-alpha.2` pour le contrat de composition des skeletons.
+
+### FAIL
+
+Consigner le résultat réel dans le history de `alpha.1`, puis corriger le cadrage dans `0.0.4-alpha.1.fix.1` ou produire un REPLAN motivé. Aucun contenu de `alpha.2` ne doit être absorbé silencieusement dans un fix.

deltas/0.0.4/alpha.2.md

@@ -0,0 +1,189 @@
+<!-- file: deltas/0.0.4/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-alpha.2 — contrat de composition des skeletons
+
+## Baseline et version
+
+Baseline : commit opérateur `bf306da` (`0.0.4-alpha.1`) après application de `history/0.0.4/alpha.1.md` avec statut `PASS`, puis push sur `origin/master`.
+
+La baseline attendue contient donc le delta, le plan et le history de `alpha.1`, sans contenu `alpha.2` préalable.
+
+Version avant application :
+
+```text
+0.0.4-alpha.1
+```
+
+Version après application :
+
+```text
+0.0.4-alpha.2
+```
+
+## Objet
+
+Matérialiser le contrat transversal annoncé par le plan `0.0.4` sans anticiper les skeletons concrets des tranches suivantes.
+
+La tranche crée `docs/rules/220-SKELETONS.md` comme propriétaire normatif unique de l'applicabilité, de la sélection, de la composition, des décisions projet, des overrides et de la validation initiale des skeleton specifications. Elle active également `docs/skeletons/` avec un index réel décrivant la responsabilité de la collection.
+
+Les index normatifs et documentaires ainsi que les deux documents d'architecture concernés sont réconciliés avec ce nouveau propriétaire. Le modèle des profils reste possédé par `docs/architecture/003-RULE_PROFILE_MODEL.md` ; le nouveau document `220` le référence au lieu de dupliquer sa hiérarchie.
+
+Aucun skeleton de fondation, Rust/Cargo, Java/Android, Web, JNI, Tauri ou autre domaine technologique n'appartient à cette tranche.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+RULES.md
+docs/000-README.md
+docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+docs/architecture/003-RULE_PROFILE_MODEL.md
+docs/rules/000-README.md
+```
+
+ADD :
+
+```text
+docs/rules/220-SKELETONS.md
+docs/skeletons/000-README.md
+deltas/0.0.4/alpha.2.md
+```
+
+DELETE : aucun.
+
+L'archive delta contient uniquement ces dix fichiers complets avec leurs chemins relatifs. Elle ne contient pas `history/0.0.4/alpha.1.md`, déjà committé dans la baseline, ni `history/0.0.4/alpha.2.md`, qui sera produit après la gate opérateur.
+
+Le plan `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` n'est pas modifié : la tranche réalise son étape `alpha.2` sans replan ni changement substantiel de trajectoire.
+
+## Décisions normatives matérialisées
+
+Le contrat commun impose notamment qu'un skeleton :
+
+- déclare son objectif et son applicabilité à partir de faits du projet ;
+- identifie les règles, profils, templates, fichiers, décisions, options, overrides, ordre utile, validation et hors-scope nécessaires ;
+- référence les owners normatifs existants au lieu de devenir propriétaire implicite de leurs règles ;
+- conserve les projets instanciés autonomes et sans dépendance runtime/build vers PGR ;
+- distingue les valeurs obligatoires, exemples, recommandations et choix libres lorsqu'une confusion serait possible ;
+- n'applique pas tous les profils PGR par défaut ;
+- n'utilise pas l'ordre de composition comme priorité normative implicite ;
+- ne crée pas de skeleton composite sans interaction réelle à posséder ;
+- utilise une validation proportionnée au contenu réellement matérialisé.
+
+La collection `docs/skeletons/` reste vide de specification concrète dans `alpha.2` hormis son index. Sa création n'est pas un placeholder : l'index documente le contrat de collection réellement activé par le nouveau owner normatif.
+
+## Validation opérateur
+
+Après application sur le commit `bf306da`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-alpha.2'
+test -f history/0.0.4/alpha.1.md
+test -f deltas/0.0.4/alpha.2.md
+test -f docs/rules/220-SKELETONS.md
+test -f docs/skeletons/000-README.md
+test ! -e history/0.0.4/alpha.2.md
+
+test ! -e docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+test ! -e docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+
+grep -Fx '<!-- version: 8 -->' README.md
+grep -Fx '<!-- version: 10 -->' RULES.md
+grep -Fx '<!-- version: 6 -->' docs/000-README.md
+grep -Fx '<!-- version: 3 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -Fx '<!-- version: 3 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
+grep -Fx '<!-- version: 11 -->' docs/rules/000-README.md
+grep -Fx '<!-- version: 1 -->' docs/rules/220-SKELETONS.md
+grep -Fx '<!-- version: 1 -->' docs/skeletons/000-README.md
+
+grep -F 'docs/rules/220-SKELETONS.md' RULES.md
+grep -F '220-SKELETONS.md' docs/rules/000-README.md
+grep -F 'skeletons/' docs/000-README.md
+grep -F '220-SKELETONS.md' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F '220-SKELETONS.md' docs/architecture/003-RULE_PROFILE_MODEL.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_counts = {'0.0.1': 12, '0.0.2': 12, '0.0.3': 10, '0.0.4': 1}
+for release, expected in expected_counts.items():
+    histories = {path.name for path in Path('history', release).glob('*.md')}
+    if release == '0.0.4':
+        assert histories == {'alpha.1.md'}, histories
+        continue
+    deltas = {path.name for path in Path('deltas', release).glob('*.md')}
+    assert len(deltas) == expected, (release, len(deltas))
+    assert deltas == histories, (release, sorted(deltas ^ histories))
+
+text = Path('history/0.0.4/alpha.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', text)
+
+assert sorted(path.name for path in Path('docs/skeletons').glob('*.md')) == ['000-README.md']
+
+rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Applicabilité',
+    '## Contenu minimal d\'une specification',
+    '## Sélection des règles et profils',
+    '## Templates et artefacts techniques',
+    '## Décisions propres au projet',
+    '## Composition de plusieurs skeletons',
+    '## Overrides et exceptions',
+    '## Validation de l\'instanciation',
+):
+    assert phrase in rule, phrase
+
+print('Skeleton contract audit: clean (alpha.1 PASS baseline, alpha.2 contract/index only)')
+PY
+
+git diff --check
+git add VERSION README.md RULES.md docs/000-README.md \
+    docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
+    docs/architecture/003-RULE_PROFILE_MODEL.md \
+    docs/rules/000-README.md docs/rules/220-SKELETONS.md \
+    docs/skeletons/000-README.md deltas/0.0.4/alpha.2.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  README.md
+M  RULES.md
+M  VERSION
+A  deltas/0.0.4/alpha.2.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/architecture/003-RULE_PROFILE_MODEL.md
+M  docs/rules/000-README.md
+A  docs/rules/220-SKELETONS.md
+A  docs/skeletons/000-README.md
+```
+
+La revue opérateur doit également confirmer que `220-SKELETONS.md` reste transversal, ne duplique pas les règles de profils ou de validation et ne matérialise aucun choix technologique futur par anticipation.
+
+## Transition
+
+### PASS
+
+Rédiger et livrer `history/0.0.4/alpha.2.md` avec les résultats réellement observés ; l'appliquer puis committer la tranche. La tranche suivante est `0.0.4-alpha.3`, consacrée à la première skeleton specification de fondation d'un projet gouverné.
+
+Le history `alpha.2` et le delta `alpha.3` MAY être livrés dans la même réponse après la gate `PASS`, tout en restant deux archives séparées. Le delta `alpha.3` MUST NOT être appliqué avant le commit complet de `alpha.2`.
+
+### FAIL
+
+Consigner le résultat réel dans le history de `alpha.2`, puis corriger le contrat dans `0.0.4-alpha.2.fix.1` ou produire un REPLAN motivé. Aucun skeleton concret de `alpha.3` ne doit être absorbé silencieusement dans un fix.

deltas/0.0.4/alpha.3.md

@@ -0,0 +1,167 @@
+<!-- file: deltas/0.0.4/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-alpha.3 — fondation de projet gouverné
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.0.4-alpha.2`, réalisé après application de `history/0.0.4/alpha.2.md` avec statut `PASS`.
+
+Le hash de ce commit n'est volontairement pas anticipé : le history `alpha.2` et le présent delta peuvent être livrés dans le même échange, mais restent deux archives séparées et le delta `alpha.3` MUST NOT être appliqué avant le commit de `alpha.2`.
+
+Version avant application :
+
+```text
+0.0.4-alpha.2
+```
+
+Version après application :
+
+```text
+0.0.4-alpha.3
+```
+
+## Objet
+
+Matérialiser la première skeleton specification concrète prévue par le plan `0.0.4` : une fondation composable de gouvernance locale pour un projet qui adopte PGR, sans sélectionner de langage, plateforme, framework ou architecture applicative.
+
+La specification doit rendre actionnables les responsabilités générales déjà possédées par `200`, `210`, `300` et `400` : version courante, point d'entrée normatif, documentation minimale, workflow réellement retenu, décisions destinataire, overrides et validation initiale proportionnée.
+
+Elle ne crée aucun template générique, ne copie pas la structure complète du dépôt PGR et ne précrée aucun répertoire documentaire ou workflow sans contenu réel.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+docs/skeletons/000-README.md
+```
+
+ADD :
+
+```text
+docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+deltas/0.0.4/alpha.3.md
+```
+
+DELETE : aucun.
+
+L'archive delta contient uniquement ces six fichiers complets avec leurs chemins relatifs. Elle ne contient ni `history/0.0.4/alpha.2.md`, livré séparément pour clôturer la tranche précédente, ni `history/0.0.4/alpha.3.md`, qui sera produit après la gate opérateur.
+
+Le plan `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` et la règle `docs/rules/220-SKELETONS.md` ne sont pas modifiés : cette tranche exécute leur trajectoire et leur contrat sans REPLAN.
+
+## Contenu matérialisé
+
+`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` :
+
+- déclare son objectif, son applicabilité et son hors-scope ;
+- sélectionne les owners généraux `200`, `210`, `300` et `400` sans sélectionner de profil technologique ;
+- distingue le rôle de `220` comme contrat d'instanciation de celui des règles à reprendre localement ;
+- impose de résoudre les décisions destinataire avant de présenter l'instanciation comme terminée ;
+- rend le point d'entrée normatif local et la version courante explicites ;
+- rend `docs/`, `ROADMAP.md`, `CHANGELOG.md` et les collections spécialisées conditionnels à un contenu réel ;
+- conserve `deltas/`, `history/`, `prompts/`, `handoffs/` et `manifests/` comme répertoires créés à la demande ;
+- fournit une validation initiale proportionnée sans imposer de copier les scripts PGR ;
+- définit l'ordre de composition attendu pour les futures spécialisations ;
+- exclut explicitement architecture applicative, toolchain, CI/CD universel, branching universel et migration rétroactive.
+
+Aucun template générique n'est nécessaire pour rendre cette specification actionnable : elle décrit les owners, décisions, fichiers conditionnels et preuves à matérialiser sans prétendre générer leur contenu automatiquement. Le point de REPLAN du plan n'est donc pas déclenché par cette tranche.
+
+## Validation opérateur
+
+Après avoir appliqué `history/0.0.4/alpha.2.md`, committé `0.0.4-alpha.2`, puis appliqué le présent delta, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-alpha.3'
+test -f history/0.0.4/alpha.2.md
+test -f deltas/0.0.4/alpha.3.md
+test -f docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+test ! -e history/0.0.4/alpha.3.md
+test ! -e docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+
+grep -Fx '<!-- version: 9 -->' README.md
+grep -Fx '<!-- version: 7 -->' docs/000-README.md
+grep -Fx '<!-- version: 2 -->' docs/skeletons/000-README.md
+grep -Fx '<!-- version: 1 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+
+grep -F '001-PROJECT_GOVERNANCE_FOUNDATION.md' README.md
+grep -F '001-PROJECT_GOVERNANCE_FOUNDATION.md' docs/000-README.md
+grep -F '001-PROJECT_GOVERNANCE_FOUNDATION.md' docs/skeletons/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
+
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == {'alpha.1.md', 'alpha.2.md'}, histories
+for name in sorted(histories):
+    text = Path('history/0.0.4', name).read_text(encoding='utf-8')
+    assert re.search(r'## Statut\s+PASS\s', text), name
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == ['000-README.md', '001-PROJECT_GOVERNANCE_FOUNDATION.md'], skeletons
+
+text = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Applicabilité',
+    '## Owners sélectionnés',
+    '## Décisions destinataire avant matérialisation',
+    '## Baseline locale à matérialiser',
+    '### Version',
+    '### Documentation minimale',
+    '### Workflow retenu',
+    '### Validation initiale',
+    '## Ordre de composition',
+    '## Overrides et exceptions',
+    '## Hors scope',
+):
+    assert phrase in text, phrase
+
+for owner in ('200-GOVERNANCE.md', '210-WORKFLOW.md', '300-DOCUMENTATION.md', '400-VALIDATION.md'):
+    assert owner in text, owner
+
+for forbidden in (
+    'templates/generic',
+    'docs/skeletons/002-RUST_CARGO_WORKSPACE.md',
+):
+    assert forbidden not in text, forbidden
+
+print('Governance foundation audit: clean (alpha.1/alpha.2 PASS baseline, one concrete non-technological skeleton)')
+PY
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/skeletons/000-README.md \
+    docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
+    deltas/0.0.4/alpha.3.md
+git diff --cached --check
+git status --short
+```
+
+## Revue opérateur
+
+En complément des commandes, vérifier que :
+
+- la fondation reste une procedure composable et non un template ou générateur implicite ;
+- aucun document ou répertoire n'est rendu obligatoire uniquement pour reproduire le layout PGR ;
+- aucune règle technologique `500+` ou `600+` n'est sélectionnée par défaut ;
+- les décisions destinataire restent explicites et aucune valeur d'exemple n'est universalisée ;
+- l'ordre de composition permet au futur skeleton Rust/Cargo d'ajouter ses responsabilités sans dupliquer les owners généraux.
+
+## Transition
+
+PASS : produire `history/0.0.4/alpha.3.md`, l'appliquer puis committer `0.0.4-alpha.3`. La tranche suivante prévue par le plan est `0.0.4-alpha.4`, consacrée au skeleton Rust/Cargo workspace et à sa validation d'instanciation.
+
+FAIL : rester dans le scope de `alpha.3` via `alpha.3.fix.1` sauf si l'échec démontre qu'un template générique ou une nouvelle décision normative est indispensable, auquel cas déclencher le REPLAN prévu par le plan.

deltas/0.0.4/alpha.4.fix.1.md

@@ -0,0 +1,231 @@
+<!-- file: deltas/0.0.4/alpha.4.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-alpha.4.fix.1 — correction du smoke Rust/Cargo
+
+## Baseline
+
+Version attendue avant application :
+
+```text
+0.0.4-alpha.4
+```
+
+Le history `history/0.0.4/alpha.4.md` avec statut `FAIL` MUST avoir été appliqué et committé avant ce correctif.
+
+Version après application :
+
+```text
+0.0.4-alpha.4.fix.1
+```
+
+## Objet
+
+Corriger uniquement la procédure de smoke Rust/Cargo qui a échoué pendant la gate opérateur de `alpha.4`.
+
+Le workspace temporaire était fonctionnel et les commandes Cargo ont réussi, mais l'adaptation de `.cargo/config.toml` remplaçait les chemins contenant `project-name` sans adapter le commentaire de guidance qui contenait encore ce placeholder. L'assertion d'absence de placeholders échouait donc avant le smoke Cargo.
+
+Ce fix adapte explicitement ce commentaire dans la fixture temporaire avant de vérifier l'absence de placeholders.
+
+Aucune règle, aucun skeleton, aucun template et aucun script PGR n'est ajouté ou modifié.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+```
+
+ADD :
+
+```text
+deltas/0.0.4/alpha.4.fix.1.md
+```
+
+DELETE : aucun.
+
+Les snapshots suivants restent inchangés :
+
+```text
+deltas/0.0.4/alpha.4.md
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+templates/rust-cargo/rustfmt.toml
+templates/rust-cargo/clippy.toml
+templates/rust-cargo/.cargo/config.toml
+templates/rust-cargo/Cargo.toml
+templates/rust-cargo/crates/project-core-lib/Cargo.toml
+```
+
+## Validation opérateur
+
+```bash
+test "$(cat VERSION)" = '0.0.4-alpha.4.fix.1'
+test -f history/0.0.4/alpha.4.md
+test -f deltas/0.0.4/alpha.4.md
+test -f deltas/0.0.4/alpha.4.fix.1.md
+test -f docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+test ! -e history/0.0.4/alpha.4.fix.1.md
+
+grep -A2 '^## Statut$' history/0.0.4/alpha.4.md | grep -Fx 'FAIL'
+
+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
+import tomllib
+
+expected = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'alpha.4.md': 'FAIL',
+}
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == set(expected), histories
+for name, status in expected.items():
+    text = Path('history/0.0.4', name).read_text(encoding='utf-8')
+    assert re.search(rf'## Statut\s+{status}\s', text), (name, status)
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == [
+    '000-README.md',
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+], skeletons
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+print('Rust/Cargo fix audit: clean (alpha.4 FAIL recorded, skeleton/templates unchanged)')
+PY
+
+command -v cargo
+command -v rustfmt
+cargo --version
+rustc --version
+rustfmt --version
+cargo clippy --version
+
+tmp="$(mktemp -d)"
+trap 'rm -rf "$tmp"' EXIT
+mkdir -p "$tmp/.cargo" "$tmp/crates/smoke-core-lib/src"
+cp templates/rust-cargo/Cargo.toml "$tmp/Cargo.toml"
+cp templates/rust-cargo/rustfmt.toml "$tmp/rustfmt.toml"
+cp templates/rust-cargo/clippy.toml "$tmp/clippy.toml"
+cp templates/rust-cargo/.cargo/config.toml "$tmp/.cargo/config.toml"
+cp templates/rust-cargo/crates/project-core-lib/Cargo.toml "$tmp/crates/smoke-core-lib/Cargo.toml"
+printf '1.2.3\n' > "$tmp/VERSION"
+
+python3 -B - "$tmp" <<'PY'
+from pathlib import Path
+import sys
+
+root = Path(sys.argv[1])
+
+replacements = {
+    root / 'Cargo.toml': (
+        ('# file: templates/rust-cargo/Cargo.toml', '# file: Cargo.toml'),
+        ('members = ["crates/project-core-lib"]', 'members = ["crates/smoke-core-lib"]'),
+        ('version = "0.1.0"', 'version = "1.2.3"'),
+    ),
+    root / 'rustfmt.toml': (
+        ('# file: templates/rust-cargo/rustfmt.toml', '# file: rustfmt.toml'),
+    ),
+    root / 'clippy.toml': (
+        ('# file: templates/rust-cargo/clippy.toml', '# file: clippy.toml'),
+    ),
+    root / '.cargo/config.toml': (
+        ('# file: templates/rust-cargo/.cargo/config.toml', '# file: .cargo/config.toml'),
+        (
+            '# Replace project-name with a unique name before using this configuration.',
+            '# Smoke fixture: project-specific build directory already selected.',
+        ),
+        ('../builds/project-name/target', 'target-smoke'),
+    ),
+    root / 'crates/smoke-core-lib/Cargo.toml': (
+        (
+            '# file: templates/rust-cargo/crates/project-core-lib/Cargo.toml',
+            '# file: crates/smoke-core-lib/Cargo.toml',
+        ),
+        ('name = "project-core-lib"', 'name = "smoke-core-lib"'),
+    ),
+}
+
+for path, pairs in replacements.items():
+    text = path.read_text(encoding='utf-8')
+    for old, new in pairs:
+        assert old in text, (path, old)
+        text = text.replace(old, new)
+    path.write_text(text, encoding='utf-8')
+
+for path in root.rglob('*'):
+    if path.is_file() and path.name != 'Cargo.lock':
+        text = path.read_text(encoding='utf-8')
+        assert 'project-name' not in text, path
+        assert 'project-core-lib' not in text, path
+
+print('Temporary Rust/Cargo template adaptation: clean')
+PY
+
+cat > "$tmp/crates/smoke-core-lib/src/lib.rs" <<'RS'
+//! Minimal crate used to validate the PGR Rust/Cargo templates.
+
+/// Returns the deterministic smoke value.
+pub fn smoke_value() -> u8 {
+    return 1;
+}
+RS
+
+(
+    cd "$tmp"
+    cargo metadata --format-version 1 --no-deps >/dev/null
+    cargo fmt --all -- --check
+    cargo check --workspace
+    cargo clippy --workspace --all-targets --all-features -- -D warnings
+)
+
+rm -rf "$tmp"
+trap - EXIT
+
+git diff --check
+
+git add VERSION deltas/0.0.4/alpha.4.fix.1.md
+
+git diff --cached --check
+git status --short
+```
+
+La sortie Git attendue avant ajout du history du fix est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/alpha.4.fix.1.md
+```
+
+## Transition
+
+### PASS
+
+Créer et appliquer séparément `history/0.0.4/alpha.4.fix.1.md`, committer et pousser le correctif, puis reprendre le plan `0.0.4` à la tranche suivante prévue.
+
+Le history `alpha.4.fix.1` et le delta de la tranche suivante MAY être livrés ensemble sous forme de deux archives séparées après observation de la gate opérateur.
+
+### FAIL
+
+Rester dans `0.0.4-alpha.4.fix.M`. Le scope MUST rester limité au smoke Rust/Cargo de cette tranche tant qu'aucun défaut plus large ne justifie un REPLAN.

deltas/0.0.4/alpha.4.md

@@ -0,0 +1,277 @@
+<!-- file: deltas/0.0.4/alpha.4.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-alpha.4 — skeleton Rust/Cargo workspace
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.0.4-alpha.3`, réalisé après application de `history/0.0.4/alpha.3.md` avec statut `PASS`.
+
+Le hash de ce commit n'est volontairement pas anticipé : le history `alpha.3` et le présent delta peuvent être livrés dans le même échange, mais restent deux archives séparées et le delta `alpha.4` MUST NOT être appliqué avant le commit de `alpha.3`.
+
+Version avant application :
+
+```text
+0.0.4-alpha.3
+```
+
+Version après application :
+
+```text
+0.0.4-alpha.4
+```
+
+## Objet
+
+Matérialiser la première specialization technologique prévue par le plan `0.0.4` : un skeleton Rust/Cargo workspace composable avec la fondation `001`, les profils `500 + 510`, les cinq templates Rust/Cargo existants et leurs guides d'adaptation.
+
+La specification doit rendre explicites les décisions destinataire avant copie, la relation entre `VERSION` et la version Cargo, les membres du workspace, l'édition/toolchain, les métadonnées, les dépendances/features, `Cargo.lock`, les lints, les paramètres Rustfmt/Clippy, les artefacts Cargo et la sélection éventuelle des audits de style Rust.
+
+Aucun template Rust/Cargo ni owner normatif n'est modifié dans cette tranche : la spécialisation doit composer les pièces déjà éprouvées sans universaliser leurs valeurs d'exemple.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+docs/skeletons/000-README.md
+```
+
+ADD :
+
+```text
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+deltas/0.0.4/alpha.4.md
+```
+
+DELETE : aucun.
+
+L'archive delta contient uniquement ces six fichiers complets avec leurs chemins relatifs. Elle ne contient ni `history/0.0.4/alpha.3.md`, livré séparément pour clôturer la tranche précédente, ni `history/0.0.4/alpha.4.md`, qui sera produit après la gate opérateur.
+
+Les documents suivants restent inchangés :
+
+```text
+docs/rules/220-SKELETONS.md
+docs/rules/500-LANGUAGES.md
+docs/rules/510-RUST_CARGO.md
+docs/templates/001-RUST_CARGO_TOOLING.md
+docs/templates/002-CARGO_MANIFESTS.md
+docs/validation/002-RUST_STYLE_AUDITS.md
+templates/rust-cargo/rustfmt.toml
+templates/rust-cargo/clippy.toml
+templates/rust-cargo/.cargo/config.toml
+templates/rust-cargo/Cargo.toml
+templates/rust-cargo/crates/project-core-lib/Cargo.toml
+```
+
+La tranche exécute donc le plan sans REPLAN et sans déplacer les propriétaires existants.
+
+## Contenu matérialisé
+
+`docs/skeletons/002-RUST_CARGO_WORKSPACE.md` :
+
+- se compose explicitement avec `001-PROJECT_GOVERNANCE_FOUNDATION.md` ;
+- sélectionne `500-LANGUAGES.md` et `510-RUST_CARGO.md` sans absorber leurs règles ;
+- référence les guides `001-RUST_CARGO_TOOLING.md` et `002-CARGO_MANIFESTS.md` ;
+- identifie exactement les cinq templates Rust/Cargo copiables existants ;
+- rend explicites les décisions de release unit, membres, édition/toolchain, publication, métadonnées, dépendances/features, lockfile, lints, formatage, Clippy et artefacts ;
+- rappelle que `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build doivent être revus avant adoption ;
+- ne fournit aucun `src/lib.rs` ou `src/main.rs` universel ;
+- conserve les audits de style Rust comme option explicitement sélectionnée avec corpus ciblé ;
+- définit une validation Cargo initiale fondée sur `cargo metadata`, Rustfmt, `cargo check` et Clippy ;
+- permet aux futurs profils plateforme/framework de s'ajouter après le workspace sans créer un composite artificiel.
+
+## Validation opérateur
+
+Après avoir appliqué `history/0.0.4/alpha.3.md`, committé `0.0.4-alpha.3`, puis appliqué le présent delta, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-alpha.4'
+test -f history/0.0.4/alpha.3.md
+test -f deltas/0.0.4/alpha.4.md
+test -f docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+test ! -e history/0.0.4/alpha.4.md
+
+grep -Fx '<!-- version: 10 -->' README.md
+grep -Fx '<!-- version: 8 -->' docs/000-README.md
+grep -Fx '<!-- version: 3 -->' docs/skeletons/000-README.md
+grep -Fx '<!-- version: 1 -->' docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+
+grep -F '002-RUST_CARGO_WORKSPACE.md' README.md
+grep -F '002-RUST_CARGO_WORKSPACE.md' docs/000-README.md
+grep -F '002-RUST_CARGO_WORKSPACE.md' docs/skeletons/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
+import tomllib
+
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == {'alpha.1.md', 'alpha.2.md', 'alpha.3.md'}, histories
+for name in sorted(histories):
+    text = Path('history/0.0.4', name).read_text(encoding='utf-8')
+    assert re.search(r'## Statut\s+PASS\s', text), name
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == [
+    '000-README.md',
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+], skeletons
+
+text = Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Applicabilité et composition',
+    '## Owners, guides et artefacts sélectionnés',
+    '## Décisions destinataire avant copie',
+    '## Matérialisation du workspace',
+    '### Cargo.lock',
+    '### Audits de style facultatifs',
+    '## Validation initiale',
+    '## Ordre de composition et extensions',
+    '## Overrides et exceptions',
+    '## Hors scope',
+):
+    assert phrase in text, phrase
+
+for owner in ('500-LANGUAGES.md', '510-RUST_CARGO.md'):
+    assert owner in text, owner
+
+for template in (
+    'templates/rust-cargo/rustfmt.toml',
+    'templates/rust-cargo/clippy.toml',
+    'templates/rust-cargo/.cargo/config.toml',
+    'templates/rust-cargo/Cargo.toml',
+    'templates/rust-cargo/crates/project-core-lib/Cargo.toml',
+):
+    assert template in text, template
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+print('Rust/Cargo skeleton audit: clean (alpha.1-alpha.3 PASS baseline, five templates parsed)')
+PY
+
+command -v cargo
+command -v rustfmt
+cargo --version
+rustc --version
+rustfmt --version
+cargo clippy --version
+
+tmp="$(mktemp -d)"
+trap 'rm -rf "$tmp"' EXIT
+mkdir -p "$tmp/.cargo" "$tmp/crates/smoke-core-lib/src"
+cp templates/rust-cargo/Cargo.toml "$tmp/Cargo.toml"
+cp templates/rust-cargo/rustfmt.toml "$tmp/rustfmt.toml"
+cp templates/rust-cargo/clippy.toml "$tmp/clippy.toml"
+cp templates/rust-cargo/.cargo/config.toml "$tmp/.cargo/config.toml"
+cp templates/rust-cargo/crates/project-core-lib/Cargo.toml "$tmp/crates/smoke-core-lib/Cargo.toml"
+printf '1.2.3\n' > "$tmp/VERSION"
+
+python3 -B - "$tmp" <<'PY'
+from pathlib import Path
+import sys
+
+root = Path(sys.argv[1])
+
+replacements = {
+    root / 'Cargo.toml': (
+        ('# file: templates/rust-cargo/Cargo.toml', '# file: Cargo.toml'),
+        ('members = ["crates/project-core-lib"]', 'members = ["crates/smoke-core-lib"]'),
+        ('version = "0.1.0"', 'version = "1.2.3"'),
+    ),
+    root / 'rustfmt.toml': (
+        ('# file: templates/rust-cargo/rustfmt.toml', '# file: rustfmt.toml'),
+    ),
+    root / 'clippy.toml': (
+        ('# file: templates/rust-cargo/clippy.toml', '# file: clippy.toml'),
+    ),
+    root / '.cargo/config.toml': (
+        ('# file: templates/rust-cargo/.cargo/config.toml', '# file: .cargo/config.toml'),
+        ('../builds/project-name/target', 'target-smoke'),
+    ),
+    root / 'crates/smoke-core-lib/Cargo.toml': (
+        ('# file: templates/rust-cargo/crates/project-core-lib/Cargo.toml', '# file: crates/smoke-core-lib/Cargo.toml'),
+        ('name = "project-core-lib"', 'name = "smoke-core-lib"'),
+    ),
+}
+
+for path, pairs in replacements.items():
+    text = path.read_text(encoding='utf-8')
+    for old, new in pairs:
+        assert old in text, (path, old)
+        text = text.replace(old, new)
+    path.write_text(text, encoding='utf-8')
+
+for path in root.rglob('*'):
+    if path.is_file() and path.name != 'Cargo.lock':
+        text = path.read_text(encoding='utf-8')
+        assert 'project-name' not in text, path
+        assert 'project-core-lib' not in text, path
+PY
+
+cat > "$tmp/crates/smoke-core-lib/src/lib.rs" <<'RS'
+//! Minimal crate used to validate the PGR Rust/Cargo templates.
+
+/// Returns the deterministic smoke value.
+pub fn smoke_value() -> u8 {
+    return 1;
+}
+RS
+
+(
+    cd "$tmp"
+    cargo metadata --format-version 1 --no-deps >/dev/null
+    cargo fmt --all -- --check
+    cargo check --workspace
+    cargo clippy --workspace --all-targets --all-features -- -D warnings
+)
+
+rm -rf "$tmp"
+trap - EXIT
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/skeletons/000-README.md \
+    docs/skeletons/002-RUST_CARGO_WORKSPACE.md \
+    deltas/0.0.4/alpha.4.md
+git diff --cached --check
+git status --short
+```
+
+## Revue opérateur
+
+En complément des commandes, vérifier que :
+
+- `002` reste une specialization composable de `001` et ne redéfinit pas les owners généraux ;
+- les cinq templates sont référencés comme artefacts à adapter, jamais comme valeurs universelles ;
+- la politique `Cargo.lock`, les membres, dépendances/features, métadonnées et éventuelles exceptions de lints/safety restent des décisions explicites du projet ;
+- les audits Rust facultatifs ne sont ni copiés ni exécutés sans sélection de leur convention et de leur corpus ;
+- aucune règle Java/Android/Web/JNI/Tauri ou autre plateforme/framework n'entre dans la tranche ;
+- l'instanciation temporaire prouve l'adoption minimale des templates sans ajouter de workspace Rust au dépôt PGR.
+
+## Transition
+
+PASS : produire `history/0.0.4/alpha.4.md`, l'appliquer puis committer `0.0.4-alpha.4`. La tranche suivante prévue par le plan est `0.0.4-beta.1`, consacrée à la réconciliation interne de la release : ownership, liens, index, duplication normative, valeurs d'exemple, limites des audits et confirmation des domaines différés.
+
+FAIL : rester dans le scope de `alpha.4` via `alpha.4.fix.1` sauf si l'instanciation démontre qu'un template ou une décision normative existante est insuffisante, auquel cas déclencher le REPLAN prévu par le plan.

deltas/0.0.4/beta.1.fix.1.md

@@ -0,0 +1,200 @@
+<!-- file: deltas/0.0.4/beta.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-beta.1.fix.1 — correction de la gate de réconciliation
+
+## Baseline et version
+
+Baseline : tranche `0.0.4-beta.1` enregistrée `FAIL`, avec `history/0.0.4/beta.1.md` appliqué, committé et poussé. Le delta et le history `beta.1` restent des snapshots historiques et MUST NOT être réécrits.
+
+Version avant application :
+
+```text
+0.0.4-beta.1
+```
+
+Version après application :
+
+```text
+0.0.4-beta.1.fix.1
+```
+
+## Motif
+
+La gate `beta.1` a échoué avant l'exécution de son audit Python de réconciliation à cause d'une chaîne délimitée par apostrophes simples contenant l'apostrophe de `l'arborescence` :
+
+```text
+SyntaxError: unterminated string literal
+```
+
+Les tests, audits Markdown et contrôles précédant cette commande ont réussi. Aucun défaut des règles, skeletons, templates ou documents vivants n'a été observé.
+
+Le présent fix corrige uniquement la gate en utilisant une chaîne Python correctement délimitée, puis rejoue les preuves nécessaires de la réconciliation.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+```
+
+ADD :
+
+```text
+deltas/0.0.4/beta.1.fix.1.md
+```
+
+DELETE : aucun.
+
+Aucun document vivant, règle, skeleton, template, script, test ou history antérieur n'est modifié.
+
+## Validation opérateur
+
+Après commit et push de `0.0.4-beta.1` avec son history `FAIL`, appliquer ce delta puis exécuter à la racine :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-beta.1.fix.1'
+git cat-file -e HEAD:history/0.0.4/beta.1.md
+test -f history/0.0.4/beta.1.md
+test -f deltas/0.0.4/beta.1.md
+test -f deltas/0.0.4/beta.1.fix.1.md
+test ! -e history/0.0.4/beta.1.fix.1.md
+
+grep -A2 '^## Statut$' history/0.0.4/beta.1.md | grep -Fx 'FAIL'
+grep -A2 '^## Statut$' history/0.0.4/alpha.4.fix.1.md | grep -Fx 'PASS'
+
+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
+import tomllib
+
+expected_histories = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'alpha.4.md': 'FAIL',
+    'alpha.4.fix.1.md': 'PASS',
+    'beta.1.md': 'FAIL',
+}
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == set(expected_histories), histories
+for name, status in expected_histories.items():
+    text = Path('history/0.0.4', 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.0.4').glob('*.md')}
+assert deltas == set(expected_histories) | {'beta.1.fix.1.md'}, deltas
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == [
+    '000-README.md',
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+], skeletons
+
+root_index = Path('README.md').read_text(encoding='utf-8')
+docs_index = Path('docs/000-README.md').read_text(encoding='utf-8')
+skel_index = Path('docs/skeletons/000-README.md').read_text(encoding='utf-8')
+for name in (
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+):
+    assert name in root_index, name
+    assert name in docs_index, name
+    assert name in skel_index, name
+
+foundation = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
+for owner in (
+    '200-GOVERNANCE.md',
+    '210-WORKFLOW.md',
+    '300-DOCUMENTATION.md',
+    '400-VALIDATION.md',
+):
+    assert owner in foundation, owner
+
+rust = Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md').read_text(encoding='utf-8')
+for owner in ('500-LANGUAGES.md', '510-RUST_CARGO.md'):
+    assert owner in rust, owner
+for value in ('0.1.0', '2024', 'project-name', 'project-core-lib'):
+    assert value in rust, value
+assert 'Ils ne deviennent jamais des valeurs universelles par simple copie.' in rust
+assert 'Cargo.lock' in rust
+
+rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
+assert 'Un skeleton sélectionne les owners normatifs applicables ; il ne redéfinit pas leur contenu.' in rule
+assert 'MUST NOT devenir une valeur universelle par simple copie' in rule
+
+validation = Path('docs/validation/001-VALIDATION_MATRIX.md').read_text(encoding='utf-8')
+for audit_id in ('PGR-MD-HEADER-001', 'PGR-MD-TABLE-001', 'PGR-NAV-001'):
+    assert audit_id in validation, audit_id
+assert "vérifie uniquement l'existence des cibles de liens Markdown locaux inline" in validation
+
+rust_audits = Path('docs/validation/002-RUST_STYLE_AUDITS.md').read_text(encoding='utf-8')
+assert 'facultatif' in rust_audits.lower()
+assert "Les audits ne modifient ni les fichiers inspectés ni l'arborescence de build." in rust_audits
+
+plan = Path('docs/plans/004-V0_0_4_SKELETONS_PLAN.md').read_text(encoding='utf-8')
+for deferred in (
+    'Java / Maven / Gradle — différé',
+    'Android — différé',
+    'Web, JNI, Tauri et autres familles absentes — différés',
+):
+    assert deferred in plan, deferred
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+print('Skeleton beta reconciliation fix audit: clean (beta.1 FAIL recorded, 3 skeleton docs, 5 TOML parsed)')
+PY
+
+git diff --check
+git add VERSION deltas/0.0.4/beta.1.fix.1.md
+git diff --cached --check
+git status --short
+```
+
+La sortie Git attendue avant ajout du history du fix est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/beta.1.fix.1.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- le `FAIL beta.1` reste visible et n'est pas réécrit ;
+- le fix ne change aucune règle, aucun skeleton, aucun template et aucun audit ;
+- `220` reste le propriétaire du contrat transversal et `001`/`002` restent des orchestrateurs/compositeurs de leurs owners ;
+- les valeurs de templates restent adaptables et non universelles ;
+- Java/Android/Web/JNI/Tauri restent différés sans placeholder anticipé.
+
+## Transition
+
+### PASS
+
+Créer et appliquer séparément `history/0.0.4/beta.1.fix.1.md`, committer et pousser le fix, puis préparer `0.0.4-rc.1`.
+
+Le history du fix et le delta `rc.1` MAY être livrés ensemble sous forme de deux archives séparées après observation de cette gate opérateur.
+
+### FAIL
+
+Enregistrer le diagnostic réel dans `history/0.0.4/beta.1.fix.1.md`, puis poursuivre par `beta.1.fix.2` limité à la réconciliation ou faire un REPLAN explicite si un défaut de contenu est réellement découvert.

deltas/0.0.4/beta.1.md

@@ -0,0 +1,225 @@
+<!-- file: deltas/0.0.4/beta.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-beta.1 — réconciliation interne des skeletons
+
+## Baseline
+
+Version attendue avant application :
+
+```text
+0.0.4-alpha.4.fix.1
+```
+
+Le history `history/0.0.4/alpha.4.fix.1.md` avec statut `PASS` MUST avoir été appliqué, committé et poussé avant ce delta. Le `FAIL` de `history/0.0.4/alpha.4.md` reste un snapshot historique et MUST NOT être réécrit.
+
+Version après application :
+
+```text
+0.0.4-beta.1
+```
+
+## Objet
+
+Exécuter la réconciliation interne prévue par `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` après la fondation gouvernée, le skeleton Rust/Cargo et la correction de sa gate d'instanciation.
+
+La revue porte sur :
+
+```text
+ownership normatif
+navigation et index
+absence de duplication normative
+composition 001 -> 002
+valeurs d'exemple non universalisées
+limites des audits et de la validation
+spécialisations technologiques différées
+continuité delta/history de 0.0.4
+```
+
+Cette tranche n'ajoute aucune fonctionnalité, aucun profil, aucun skeleton, aucun template et aucun audit.
+
+## Résultat de la réconciliation préparatoire
+
+Aucune correction de document vivant n'est nécessaire pour entrer en beta.
+
+Le contrat transversal reste possédé par `docs/rules/220-SKELETONS.md`. La fondation `001-PROJECT_GOVERNANCE_FOUNDATION.md` orchestre les owners généraux sans les redéfinir. La specialization `002-RUST_CARGO_WORKSPACE.md` ajoute uniquement `500 + 510`, les guides/templates Rust/Cargo et les décisions de son scope.
+
+La navigation courante expose les deux specifications depuis `README.md`, `docs/000-README.md` et `docs/skeletons/000-README.md`. Aucun troisième skeleton ou placeholder de skeleton n'existe.
+
+Les valeurs Rust/Cargo telles que `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build restent explicitement décrites comme exemples, baselines ou décisions destinataire à revoir. `Cargo.lock` reste une décision propre au type de produit et au besoin de reproductibilité.
+
+Les limites des audits restent séparées : headers, tableaux et liens Markdown sont des contrôles monotâches ; les audits de style Rust sont facultatifs, read-only et ne remplacent ni Rustfmt, ni Clippy, ni la toolchain Cargo. La validation d'instanciation appartient au skeleton qui prétend matérialiser une baseline utilisable et n'est pas transformée en build global permanent de PGR.
+
+Java/Maven/Gradle et Android possèdent des profils normatifs mais pas encore les templates/corpus nécessaires à un skeleton concret. Web, JNI, Tauri et les autres domaines insuffisamment cadrés restent également différés. Aucun fichier placeholder n'est créé pour réserver ces futurs scopes.
+
+Le `FAIL` de `alpha.4` et le `PASS` attendu de `alpha.4.fix.1` forment une chaîne historique explicite ; le fix ne réécrit pas le delta ou le history échoué.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+```
+
+ADD :
+
+```text
+deltas/0.0.4/beta.1.md
+```
+
+DELETE : aucun.
+
+Les documents vivants, règles, skeletons, templates, scripts, tests et histories antérieurs restent inchangés. Cette absence de modification supplémentaire est intentionnelle : la réconciliation n'a pas identifié de correction réelle qui justifierait une révision artificielle.
+
+## Validation opérateur
+
+Après commit et push de `0.0.4-alpha.4.fix.1`, appliquer ce delta puis exécuter à la racine :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-beta.1'
+git cat-file -e HEAD:history/0.0.4/alpha.4.fix.1.md
+test -f history/0.0.4/alpha.4.fix.1.md
+test -f deltas/0.0.4/beta.1.md
+test ! -e history/0.0.4/beta.1.md
+
+test -f docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+test -f docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+test ! -e docs/skeletons/003-JAVA_MAVEN_GRADLE.md
+test ! -e docs/skeletons/003-ANDROID.md
+
+grep -A2 '^## Statut$' history/0.0.4/alpha.4.md | grep -Fx 'FAIL'
+grep -A2 '^## Statut$' history/0.0.4/alpha.4.fix.1.md | grep -Fx 'PASS'
+
+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
+import tomllib
+
+expected_histories = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'alpha.4.md': 'FAIL',
+    'alpha.4.fix.1.md': 'PASS',
+}
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == set(expected_histories), histories
+for name, status in expected_histories.items():
+    text = Path('history/0.0.4', 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.0.4').glob('*.md')}
+assert deltas == set(expected_histories) | {'beta.1.md'}, deltas
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == [
+    '000-README.md',
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+], skeletons
+
+root_index = Path('README.md').read_text(encoding='utf-8')
+docs_index = Path('docs/000-README.md').read_text(encoding='utf-8')
+skel_index = Path('docs/skeletons/000-README.md').read_text(encoding='utf-8')
+for name in (
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+):
+    assert name in root_index, name
+    assert name in docs_index, name
+    assert name in skel_index, name
+
+foundation = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
+for owner in (
+    '200-GOVERNANCE.md',
+    '210-WORKFLOW.md',
+    '300-DOCUMENTATION.md',
+    '400-VALIDATION.md',
+):
+    assert owner in foundation, owner
+
+rust = Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md').read_text(encoding='utf-8')
+for owner in ('500-LANGUAGES.md', '510-RUST_CARGO.md'):
+    assert owner in rust, owner
+for value in ('0.1.0', '2024', 'project-name', 'project-core-lib'):
+    assert value in rust, value
+assert 'Ils ne deviennent jamais des valeurs universelles par simple copie.' in rust
+assert 'Cargo.lock' in rust
+
+rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
+assert 'Un skeleton sélectionne les owners normatifs applicables ; il ne redéfinit pas leur contenu.' in rule
+assert 'MUST NOT devenir une valeur universelle par simple copie' in rule
+
+validation = Path('docs/validation/001-VALIDATION_MATRIX.md').read_text(encoding='utf-8')
+for audit_id in ('PGR-MD-HEADER-001', 'PGR-MD-TABLE-001', 'PGR-NAV-001'):
+    assert audit_id in validation, audit_id
+assert 'vérifie uniquement l\'existence des cibles de liens Markdown locaux inline' in validation
+
+rust_audits = Path('docs/validation/002-RUST_STYLE_AUDITS.md').read_text(encoding='utf-8')
+assert 'facultatif' in rust_audits.lower()
+assert 'Les audits ne modifient ni les fichiers inspectés ni l'arborescence de build.' in rust_audits
+
+plan = Path('docs/plans/004-V0_0_4_SKELETONS_PLAN.md').read_text(encoding='utf-8')
+for deferred in ('Java / Maven / Gradle — différé', 'Android — différé', 'Web, JNI, Tauri et autres familles absentes — différés'):
+    assert deferred in plan, deferred
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+print('Skeleton beta reconciliation audit: clean (5 prior histories, 3 skeleton docs, 5 TOML parsed)')
+PY
+
+git diff --check
+git add VERSION deltas/0.0.4/beta.1.md
+git diff --cached --check
+git status --short
+```
+
+La sortie Git attendue avant ajout du history `beta.1` est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/beta.1.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- `220` reste le propriétaire du contrat transversal et que `001`/`002` n'en dupliquent pas les obligations ;
+- `001` reste sans spécialisation technologique et `002` n'élargit pas `510` vers Android, WASM, Tauri, FFI ou un framework ;
+- les valeurs de templates restent des exemples adaptables et non des politiques globales ;
+- les audits documentaires et Rust restent délimités par leur propriété réellement vérifiée ;
+- Java/Android/Web/JNI/Tauri restent différés faute de pièces suffisantes, sans placeholder ni skeleton composite anticipé ;
+- le `FAIL alpha.4` reste visible et la correction `alpha.4.fix.1` est enregistrée séparément.
+
+## Transition
+
+### PASS
+
+Créer et appliquer séparément `history/0.0.4/beta.1.md`, committer et pousser `beta.1`, puis préparer `0.0.4-rc.1`.
+
+La RC doit geler le scope, préparer l'entrée candidate `0.0.4` du changelog et `prompts/005-V0_0_5_START_PROMPT.md` si la trajectoire est confirmée, puis rejouer uniquement les validations réellement invalidées par la release.
+
+Le history `beta.1` et le delta `rc.1` MAY être livrés ensemble sous forme de deux archives séparées après observation de la gate opérateur.
+
+### FAIL
+
+Enregistrer le diagnostic réel dans `history/0.0.4/beta.1.md`, puis corriger uniquement la réconciliation dans `0.0.4-beta.1.fix.N` ou faire un REPLAN explicite si un défaut révèle un changement de scope.

deltas/0.0.4/rc.1.md

@@ -0,0 +1,265 @@
+<!-- file: deltas/0.0.4/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4-rc.1 — gel du scope et préparation de release
+
+## Baseline et version
+
+Baseline : `0.0.4-beta.1.fix.1`, avec `history/0.0.4/beta.1.fix.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Le commit exact de cette baseline sera celui produit par l'opérateur après la gate `beta.1.fix.1` ; il n'est pas anticipé dans cette livraison simultanée du history et du delta suivant.
+
+Version avant application :
+
+```text
+0.0.4-beta.1.fix.1
+```
+
+Version après application :
+
+```text
+0.0.4-rc.1
+```
+
+## Objet et gel
+
+La réconciliation `beta.1.fix.1` est `PASS`. La RC gèle le scope fonctionnel de `0.0.4` sur :
+
+- le contrat transversal des skeleton specifications sous `docs/rules/220-SKELETONS.md` ;
+- la collection `docs/skeletons/` et son index ;
+- `001-PROJECT_GOVERNANCE_FOUNDATION.md` comme fondation composable sans spécialisation technologique ;
+- `002-RUST_CARGO_WORKSPACE.md` comme première spécialisation technologique, composée avec les profils `500 + 510` ;
+- les cinq templates Rust/Cargo déjà introduits avant `0.0.4`, utilisés avec des décisions destinataire explicites et une instanciation temporaire vérifiable.
+
+Le changelog reçoit une entrée candidate `0.0.4` orientée utilisateurs. Le plan enregistre les résultats `FAIL → fix PASS` des gates `alpha.4` et `beta.1`, puis le gel RC. Le prompt `005` prépare `0.0.5`, dont la roadmap confirme la mission de réconciliation réelle avec `khadhroony-solana-project` et `sasedev-games` à partir de baselines explicitement fournies.
+
+Aucun nouveau skeleton, profil, template, audit, générateur ou domaine technologique n'entre en RC. Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles différées restent hors scope.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+CHANGELOG.md
+docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+ADD :
+
+```text
+prompts/005-V0_0_5_START_PROMPT.md
+deltas/0.0.4/rc.1.md
+```
+
+DELETE : aucun.
+
+L'archive contient exactement ces fichiers complets. Le history `beta.1.fix.1` est livré séparément ; le history `rc.1` sera produit après la gate opérateur.
+
+## Gate opérateur de release candidate
+
+Après application sur le commit `beta.1.fix.1`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4-rc.1'
+git cat-file -e HEAD:history/0.0.4/beta.1.fix.1.md
+test -f history/0.0.4/beta.1.fix.1.md
+test -f deltas/0.0.4/rc.1.md
+test -f prompts/005-V0_0_5_START_PROMPT.md
+test ! -e history/0.0.4/rc.1.md
+
+grep -Fx '<!-- version: 6 -->' CHANGELOG.md
+grep -Fx '## 0.0.4 (candidate)' CHANGELOG.md
+grep -Fx '<!-- version: 2 -->' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+grep -F '`beta.1.fix.1` a rejoué la réconciliation et est `PASS`' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+grep -F 'pgr-v0.0.4.zip' prompts/005-V0_0_5_START_PROMPT.md
+grep -F 'khadhroony-solana-project' prompts/005-V0_0_5_START_PROMPT.md
+grep -F 'sasedev-games' prompts/005-V0_0_5_START_PROMPT.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
+import tomllib
+
+expected_histories = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'alpha.4.md': 'FAIL',
+    'alpha.4.fix.1.md': 'PASS',
+    'beta.1.md': 'FAIL',
+    'beta.1.fix.1.md': 'PASS',
+}
+histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
+assert histories == set(expected_histories), histories
+for name, status in expected_histories.items():
+    text = Path('history/0.0.4', 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.0.4').glob('*.md')}
+assert deltas == set(expected_histories) | {'rc.1.md'}, deltas
+
+skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
+assert skeletons == [
+    '000-README.md',
+    '001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    '002-RUST_CARGO_WORKSPACE.md',
+], skeletons
+
+rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
+assert 'Un skeleton sélectionne les owners normatifs applicables ; il ne redéfinit pas leur contenu.' in rule
+
+foundation = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
+for owner in ('200-GOVERNANCE.md', '210-WORKFLOW.md', '300-DOCUMENTATION.md', '400-VALIDATION.md'):
+    assert owner in foundation, owner
+
+rust = Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md').read_text(encoding='utf-8')
+for owner in ('500-LANGUAGES.md', '510-RUST_CARGO.md'):
+    assert owner in rust, owner
+assert 'Ils ne deviennent jamais des valeurs universelles par simple copie.' in rust
+
+for path in (
+    Path('templates/rust-cargo/rustfmt.toml'),
+    Path('templates/rust-cargo/clippy.toml'),
+    Path('templates/rust-cargo/.cargo/config.toml'),
+    Path('templates/rust-cargo/Cargo.toml'),
+    Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
+):
+    with path.open('rb') as stream:
+        tomllib.load(stream)
+
+prompt = Path('prompts/005-V0_0_5_START_PROMPT.md').read_text(encoding='utf-8')
+for value in ('pgr-v0.0.4.zip', 'pgr-0.0.4-publish.001-report.md', '0.0.5-alpha.1', 'khadhroony-solana-project', 'sasedev-games'):
+    assert value in prompt, value
+assert 'Ne pas déduire leur version, leur commit ou leur contenu' in prompt
+
+print('RC integration audit: clean (7 prior histories, 3 skeleton docs, 5 TOML parsed, prompt 005 ready)')
+PY
+
+command -v cargo
+command -v rustfmt
+cargo --version
+rustc --version
+rustfmt --version
+cargo clippy --version
+
+tmp="$(mktemp -d)"
+trap 'rm -rf "$tmp"' EXIT
+mkdir -p "$tmp/.cargo" "$tmp/crates/smoke-core-lib/src"
+cp templates/rust-cargo/Cargo.toml "$tmp/Cargo.toml"
+cp templates/rust-cargo/rustfmt.toml "$tmp/rustfmt.toml"
+cp templates/rust-cargo/clippy.toml "$tmp/clippy.toml"
+cp templates/rust-cargo/.cargo/config.toml "$tmp/.cargo/config.toml"
+cp templates/rust-cargo/crates/project-core-lib/Cargo.toml "$tmp/crates/smoke-core-lib/Cargo.toml"
+printf '1.2.3\n' > "$tmp/VERSION"
+
+python3 -B - "$tmp" <<'PY'
+from pathlib import Path
+import sys
+
+root = Path(sys.argv[1])
+replacements = {
+    root / 'Cargo.toml': (
+        ('# file: templates/rust-cargo/Cargo.toml', '# file: Cargo.toml'),
+        ('members = ["crates/project-core-lib"]', 'members = ["crates/smoke-core-lib"]'),
+        ('version = "0.1.0"', 'version = "1.2.3"'),
+    ),
+    root / 'rustfmt.toml': (
+        ('# file: templates/rust-cargo/rustfmt.toml', '# file: rustfmt.toml'),
+    ),
+    root / 'clippy.toml': (
+        ('# file: templates/rust-cargo/clippy.toml', '# file: clippy.toml'),
+    ),
+    root / '.cargo/config.toml': (
+        ('# file: templates/rust-cargo/.cargo/config.toml', '# file: .cargo/config.toml'),
+        (
+            '# Replace project-name with a unique name before using this configuration.',
+            '# Smoke fixture: project-specific build directory already selected.',
+        ),
+        ('../builds/project-name/target', 'target-smoke'),
+    ),
+    root / 'crates/smoke-core-lib/Cargo.toml': (
+        (
+            '# file: templates/rust-cargo/crates/project-core-lib/Cargo.toml',
+            '# file: crates/smoke-core-lib/Cargo.toml',
+        ),
+        ('name = "project-core-lib"', 'name = "smoke-core-lib"'),
+    ),
+}
+for path, pairs in replacements.items():
+    text = path.read_text(encoding='utf-8')
+    for old, new in pairs:
+        assert old in text, (path, old)
+        text = text.replace(old, new)
+    path.write_text(text, encoding='utf-8')
+for path in root.rglob('*'):
+    if path.is_file() and path.name != 'Cargo.lock':
+        text = path.read_text(encoding='utf-8')
+        assert 'project-name' not in text, path
+        assert 'project-core-lib' not in text, path
+print('RC temporary Rust/Cargo template adaptation: clean')
+PY
+
+cat > "$tmp/crates/smoke-core-lib/src/lib.rs" <<'RS'
+//! Minimal crate used to validate the PGR Rust/Cargo templates.
+
+/// Returns the deterministic smoke value.
+pub fn smoke_value() -> u8 {
+    return 1;
+}
+RS
+
+(
+    cd "$tmp"
+    cargo metadata --format-version 1 --no-deps >/dev/null
+    cargo fmt --all -- --check
+    cargo check --workspace
+    cargo clippy --workspace --all-targets --all-features -- -D warnings
+)
+
+rm -rf "$tmp"
+trap - EXIT
+
+git diff --check
+git add VERSION CHANGELOG.md docs/plans/004-V0_0_4_SKELETONS_PLAN.md \
+    prompts/005-V0_0_5_START_PROMPT.md deltas/0.0.4/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.0.4/rc.1.md
+M  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+A  prompts/005-V0_0_5_START_PROMPT.md
+```
+
+## Revue opérateur complémentaire
+
+Confirmer que le changelog décrit la release et non ses tranches internes, que les deux `FAIL` historiques restent visibles avec leurs fixes `PASS`, que le prompt `005` ne présume aucune version KSP/Games non fournie et que la RC n'étend pas le périmètre fonctionnel.
+
+Une gate RC `PASS` n'est ni la promotion stable, ni le tag `v0.0.4`, ni la vérification de l'archive publiée après le tag.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.0.4/rc.1.md`, l'appliquer puis committer/pousser la RC avant le delta stable `rel.001`.
+
+Le history RC et le delta stable MAY être livrés ensemble sous forme de deux archives séparées après observation de cette gate opérateur.
+
+### FAIL
+
+Consigner l'échec réel dans `history/0.0.4/rc.1.md` et corriger uniquement le scope gelé dans `rc.1.fix.1`, sauf REPLAN explicite si la candidate révèle un défaut fonctionnel plus large.

deltas/0.0.4/rel.001.md

@@ -0,0 +1,152 @@
+<!-- file: deltas/0.0.4/rel.001.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.4 rel.001 — promotion stable pré-tag
+
+## Baseline et version
+
+Baseline : `0.0.4-rc.1`, avec `history/0.0.4/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Le commit exact de cette baseline sera celui produit par l'opérateur après application du history RC ; il n'est pas anticipé dans cette livraison simultanée du history et du delta stable.
+
+Version avant application :
+
+```text
+0.0.4-rc.1
+```
+
+Version après application :
+
+```text
+0.0.4
+```
+
+`rel.001` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
+
+## Objet
+
+Promouvoir la RC validée vers la stable `0.0.4`. La tranche finalise uniquement la présentation de la release : version stable, roadmap terminée, changelog sans marqueur candidate, index documentaires et plan historique.
+
+Le scope fonctionnel reste celui validé en RC : contrat transversal des skeleton specifications, fondation gouvernée `001`, spécialisation Rust/Cargo `002`, utilisation gouvernée des cinq templates Rust/Cargo existants et différé explicite des autres familles non suffisamment matérialisées.
+
+La validation de cette tranche est **pré-tag**. Ni le tag `v0.0.4`, ni l'archive `pgr-v0.0.4.zip` téléchargée depuis Gitea, ni un rapport `pgr-0.0.4-publish.001-report.md` ne sont déclarés existants par ce delta. Ils suivent le history PASS, le commit stable et la publication réelle du tag.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.0.4/rel.001.md
+```
+
+DELETE : aucun.
+
+L'archive contient uniquement ces fichiers complets. `history/0.0.4/rc.1.md` est livré séparément ; le history de `rel.001` sera produit après sa gate. Le rapport post-tag restera extérieur à l'archive source taggée.
+
+## Validation opérateur pré-tag
+
+Après application sur le commit `rc.1`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.4'
+git cat-file -e HEAD:history/0.0.4/rc.1.md
+test -f history/0.0.4/rc.1.md
+test -f deltas/0.0.4/rel.001.md
+test -f prompts/005-V0_0_5_START_PROMPT.md
+test ! -e history/0.0.4/rel.001.md
+
+grep -Fx '<!-- version: 11 -->' README.md
+grep -Fx '<!-- version: 5 -->' ROADMAP.md
+grep -Fx '<!-- version: 7 -->' CHANGELOG.md
+grep -Fx '<!-- version: 9 -->' docs/000-README.md
+grep -Fx '<!-- version: 3 -->' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+grep -F 'La release `0.0.4` définit le contrat transversal des skeleton specifications' README.md
+grep -F 'plan historique des skeleton specifications `0.0.4`' README.md
+grep -F -- '- `(x) 0.0.4`' ROADMAP.md
+grep -Fx '## 0.0.4' CHANGELOG.md
+grep -F 'périmètre et décisions de la release `0.0.4`' docs/000-README.md
+grep -F 'La gate opérateur de `rc.1` est `PASS`' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+grep -F 'pgr-0.0.4-publish.001-report.md' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+expected = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'alpha.4.md': 'FAIL',
+    'alpha.4.fix.1.md': 'PASS',
+    'beta.1.md': 'FAIL',
+    'beta.1.fix.1.md': 'PASS',
+    'rc.1.md': 'PASS',
+}
+for name, status in expected.items():
+    delta = Path('deltas/0.0.4', name)
+    history = Path('history/0.0.4', 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 = {p.name for p in Path('deltas/0.0.4').glob('*.md')} - \
+          {p.name for p in Path('history/0.0.4').glob('*.md')}
+assert pending == {'rel.001.md'}, pending
+print('Stable history audit: clean (8 prior histories with expected statuses, rel.001 pending)')
+PY
+
+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/004-V0_0_4_SKELETONS_PLAN.md deltas/0.0.4/rel.001.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.0.4/rel.001.md
+M  docs/000-README.md
+M  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+Les `15` tests, les cinq TOML et le smoke Rust/Cargo complets validés en RC restent des preuves applicables parce qu'aucun code, script, test, template ou skeleton technique n'est modifié pendant `rel.001`. La gate stable se concentre donc sur l'intégrité de la chaîne historique, la présentation stable et les audits documentaires affectés.
+
+## Revue opérateur complémentaire
+
+Confirmer que le scope fonctionnel de la RC ne change pas, que README/roadmap/changelog/index/plan décrivent la même stable, que les `FAIL` historiques restent conservés avec leurs fixes `PASS`, que le prompt `005` reste conditionnel à une vraie publication et à des baselines KSP/Games fournies, et qu'aucune preuve post-tag n'est anticipée.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.0.4/rel.001.md`, l'appliquer puis committer la stable. Ensuite seulement créer et publier le tag canonique `v0.0.4`, télécharger son archive source depuis Gitea, vérifier cette archive et conserver séparément la preuve post-tag `pgr-0.0.4-publish.001-report.md`.
+
+Le message manuel de reprise de `prompts/005-V0_0_5_START_PROMPT.md` n'est remis à l'opérateur qu'après vérification effective de l'archive et d'un rapport post-tag PASS réel.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.0.4/rel.001.md`, ne pas tagger et corriger la clôture dans une tranche explicite avant publication.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 4 -->
+<!-- version: 9 -->
 
 # Documentation PGR
 
@@ -11,6 +11,7 @@ Ce fichier est l'index d'entrée de la documentation structurée de Project Gove
 - [`architecture/`](architecture/) — état architectural courant de PGR et profils applicables ;
 - [`plans/`](plans/) — plans vivants des releases en cours, puis références historiques après fermeture ;
 - [`rules/`](rules/) — règles normatives détaillées, organisées progressivement par scope ;
+- [`skeletons/`](skeletons/) — spécifications Markdown de composition et d'initialisation de projets ;
 - [`templates/`](templates/) — instructions d'adaptation des templates techniques et spécification du message manuel de reprise ;
 - [`validation/`](validation/) — matrices de validation et contrats de preuve.
 
@@ -18,9 +19,13 @@ 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.0.3
+## Points d'entrée de 0.0.4
 
 - [`plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — périmètre et décisions de la release `0.0.3` ;
+- [`plans/004-V0_0_4_SKELETONS_PLAN.md`](plans/004-V0_0_4_SKELETONS_PLAN.md) — périmètre et décisions de la release `0.0.4` ;
+- [`skeletons/000-README.md`](skeletons/000-README.md) — contrat de collection des skeleton specifications ;
+- [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation de gouvernance locale composable et sans spécialisation technologique ;
+- [`skeletons/002-RUST_CARGO_WORKSPACE.md`](skeletons/002-RUST_CARGO_WORKSPACE.md) — specialization Rust/Cargo workspace composable avec la fondation et les cinq templates existants ;
 - [`templates/001-RUST_CARGO_TOOLING.md`](templates/001-RUST_CARGO_TOOLING.md) et [`templates/002-CARGO_MANIFESTS.md`](templates/002-CARGO_MANIFESTS.md) — adaptation des cinq fichiers Rust/Cargo copiables ;
 - [`templates/003-NEW_SESSION_PROMPT.md`](templates/003-NEW_SESSION_PROMPT.md) — spécification du message manuel après une stable publiée ;
 - [`validation/001-VALIDATION_MATRIX.md`](validation/001-VALIDATION_MATRIX.md) et [`validation/002-RUST_STYLE_AUDITS.md`](validation/002-RUST_STYLE_AUDITS.md) — gates PGR et limites des audits de style Rust facultatifs.

docs/architecture/002-GOVERNANCE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Architecture de gouvernance PGR
 
@@ -25,9 +25,9 @@ Après instanciation, le projet possède sa copie et ne dépend plus de PGR.
 
 Un skeleton est une recette Markdown décrivant comment initialiser un type de projet ou composer plusieurs profils.
 
-Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base.
+Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base. Le contrat transversal de sélection et de composition appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md) ; les spécifications concrètes sont indexées sous [`../skeletons/`](../skeletons/000-README.md).
 
-Un skeleton n'est pas un générateur et ne doit pas figer l'évolution future du projet.
+Un skeleton n'est pas un générateur et ne doit pas figer l'évolution future du projet. Il orchestre des owners normatifs et des artefacts existants sans devenir lui-même propriétaire d'une règle déjà possédée ailleurs.
 
 ### Audit
 
@@ -44,11 +44,11 @@ Le flux conceptuel est :
 ```text
 PGR rules + templates + skeleton specifications
                     ↓
-        sélection humaine / IA
+    applicabilité + décisions du projet
                     ↓
-             nouveau projet
+      copie / adaptation contrôlée
                     ↓
-       copies et règles locales
+       validation de la baseline
                     ↓
       projet autonome et gouverné
 ```

docs/architecture/003-RULE_PROFILE_MODEL.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Modèle de profils de règles PGR
 
@@ -196,8 +196,8 @@ La revue beta n'a pas justifié l'activation d'une famille `700 — frameworks`
 
 La réconciliation a également confirmé qu'une règle générale ne doit pas être recopiée comme si le profil spécifique en devenait propriétaire. Un profil peut rappeler une conséquence spécifique au contexte, mais doit référencer l'owner général lorsque le contrat lui-même n'est pas spécialisé.
 
-## Instanciation future
+## Instanciation par skeleton
 
-Les futures skeleton specifications sélectionneront les profils applicables et recopieront leurs règles pertinentes dans la baseline locale du projet créé.
+Les skeleton specifications sélectionnent les profils applicables et identifient les règles à reprendre ou adapter dans la baseline locale du projet créé. Leur contrat transversal de composition appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md) ; le présent document reste propriétaire de la hiérarchie et de la résolution des profils eux-mêmes.
 
-Le projet instancié restera autonome : la composition de profils sert à construire sa baseline initiale, pas à créer une dépendance dynamique vers PGR.
+Le projet instancié reste autonome : la composition de profils sert à construire sa baseline initiale, pas à créer une dépendance dynamique vers PGR.

docs/plans/004-V0_0_4_SKELETONS_PLAN.md

@@ -0,0 +1,158 @@
+<!-- file: docs/plans/004-V0_0_4_SKELETONS_PLAN.md -->
+<!-- version: 3 -->
+
+# Plan 0.0.4 — skeleton specifications et composition
+
+## Statut et sources
+
+Plan historique créé pendant `0.0.4-alpha.1` après audit indépendant de la stable publiée `v0.0.3` demandé par `prompts/004-V0_0_4_START_PROMPT.md`. Les tranches `alpha.1` à `alpha.3` sont `PASS`. `alpha.4` a enregistré `FAIL` sur sa gate d'instanciation, puis `alpha.4.fix.1` a corrigé cette gate et est `PASS`. `beta.1` a enregistré `FAIL` sur une erreur de syntaxe de sa gate de réconciliation, puis `beta.1.fix.1` a rejoué la réconciliation et est `PASS`. La gate opérateur de `rc.1` est `PASS` : intégration documentaire, prompt `005`, cinq TOML et instanciation temporaire Rust/Cargo avec `cargo metadata`, `fmt`, `check` et `clippy -D warnings` ont été validés. Le scope fonctionnel est gelé et `rel.001` ne réalise qu'une promotion stable pré-tag.
+
+La baseline autoritaire est l'archive source fournie `pgr-v0.0.3.zip`, déclarée téléchargée depuis le tag Gitea `v0.0.3`. Son SHA-256 vérifié pendant le cadrage est :
+
+```text
+517fb46ada098fdc221ae53a8ff4b409b81e0244ec5ce4d0e6fca0c3da61b866
+```
+
+Le rapport externe `pgr-0.0.3-publish.001-report.md` est fourni séparément, conclut `PASS` et annonce le même hash. Il atteste une vérification post-tag distincte et ne fait pas partie de la stable. L'archive source ne contient pas `.git`, ce qui est conforme au contrat de reprise ; l'identité du commit et du tag décrite dans le rapport n'est pas déduite du contenu du ZIP.
+
+Les règles applicables au cadrage sont `RULES.md`, les familles `200`, `210`, `300`, `400`, `500`, `510`, `520`, `600`, `610`, ainsi que `docs/architecture/003-RULE_PROFILE_MODEL.md`. Les guides `docs/templates/001` à `003`, les cinq modèles Rust/Cargo, les trois audits Markdown et les deux audits facultatifs de style Rust complètent l'inventaire réel de la stable.
+
+## Audit indépendant de la stable `v0.0.3`
+
+L'archive fournie est lisible et son contenu distribué est cohérent dans les contrôles effectués :
+
+- SHA-256 égal au rapport post-tag ;
+- `140` entrées ZIP : `115` fichiers et `25` répertoires, avec une seule racine `pgr/` ;
+- test CRC propre, aucun doublon, aucune collision de casse, aucun chemin absolu ou avec traversée `..`, aucun chemin Windows ambigu et aucun lien symbolique ;
+- extraction propre de `115` fichiers ; `VERSION` contient exactement `0.0.3` suivi d'un retour à la ligne ; `.git` est absent comme attendu ;
+- les fichiers distribués sont UTF-8, sans octet NUL, retour CR, espace de fin de ligne ou retour final manquant ;
+- aucun chemin distribué de build/cache ou secret contrôlé n'est présent ; `.settings/org.eclipse.core.resources.prefs` reste l'exception Eclipse versionnée prévue ;
+- `99` fichiers Markdown possèdent des headers `file/version` mécaniquement conformes ;
+- les trois audits Markdown sont propres : `99` fichiers pour les headers, `3` tableaux et `79` liens locaux ;
+- les `15` tests Python ciblés réussissent ;
+- les cinq fichiers TOML sous `templates/rust-cargo/` se parsèrent correctement ;
+- les deux audits de style Rust facultatifs n'ont pas de corpus Rust produit à inspecter dans PGR ; leur comportement est couvert par `tests/test_rust_audits.py` et leur sélection doit rester explicite dans un projet destinataire.
+
+La chaîne workflow est complète :
+
+```text
+0.0.1 : 12 deltas / 12 histories
+0.0.2 : 12 deltas / 12 histories
+0.0.3 : 10 deltas / 10 histories
+```
+
+Chaque delta possède son history homonyme. Les histories `0.0.3`, de `alpha.1` à `rel.001`, sont tous `PASS`. Les échecs historiques des séries antérieures sont conservés comme snapshots et sont suivis par leurs corrections explicites ; ils ne sont pas réécrits rétroactivement.
+
+Les limites annoncées restent visibles et cohérentes : l'audit des liens ne valide pas les anchors, l'audit des headers ne juge pas la pertinence sémantique d'une révision, les audits Rust utilisent une analyse lexicale ciblée et l'archive source ne prouve pas elle-même une référence Git distante. Aucun de ces points ne constitue un défaut bloquant de la stable.
+
+## Revue des règles, profils et propriétaires
+
+La hiérarchie normative reste cohérente avec le modèle de profils : règles générales, langage/écosystème, plateforme, puis scopes plus spécifiques et exceptions explicites. Aucun profil n'est applicable par simple fréquence ou provenance historique.
+
+Les responsabilités utiles à `0.0.4` sont distinctes :
+
+- `200` possède le lifecycle et le rôle de `alpha.1` comme gate de cadrage ;
+- `210` possède plans, deltas, histories, prompts, baselines et séparation pré-tag/post-tag ;
+- `300` possède rôles documentaires, documents vivants, snapshots et headers ;
+- `400` possède la sélection proportionnelle des preuves et l'autorité du gate opérateur ;
+- `500` et `600` possèdent les contrats communs des profils langage et plateforme ;
+- `510`, `520` et `610` possèdent respectivement Rust/Cargo, Java/Maven/Gradle et Android ;
+- `docs/architecture/003-RULE_PROFILE_MODEL.md` possède le modèle de composition et interdit les profils composites sans contrat propre réel.
+
+La séparation règle / template / skeleton / audit de `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` reste adaptée. `0.0.4` doit l'étendre par des artefacts concrets sans déplacer les propriétaires normatifs existants.
+
+## Inventaire des capacités disponibles pour des skeletons
+
+### Fondation gouvernée PGR — prête à être spécifiée
+
+Une baseline de projet gouverné constitue une fondation composable, pas une architecture applicative. Les contrats nécessaires existent déjà : versioning, workflow, documentation, validation et modèle de profils. Le skeleton devra indiquer quels artefacts locaux créer ou copier, comment sélectionner les règles réellement applicables et quelles décisions restent propres au projet.
+
+Il ne doit pas recopier l'historique de PGR, imposer toutes les familles de règles ni créer une dépendance dynamique vers le dépôt PGR.
+
+### Rust/Cargo workspace — prêt à être spécifié
+
+Le besoin est suffisamment couvert par des artefacts réels : profil `510`, deux guides d'adaptation, cinq templates Rust/Cargo et deux audits de style facultatifs documentés. Le skeleton pourra composer une fondation gouvernée avec `500 + 510` et sélectionner uniquement les templates nécessaires.
+
+Les décisions destinataire restent explicites : nom du projet et des crates, version de release, édition/toolchain, métadonnées de publication, membres du workspace, dépendances et features, politique `Cargo.lock`, chemin des artefacts Cargo, seuils Clippy, politique de lints et sélection éventuelle des audits de style. Les valeurs d'exemple `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build ne deviennent jamais universels.
+
+### Java / Maven / Gradle — différé
+
+Le profil `520` définit des règles, mais PGR ne possède encore aucun template Maven/Gradle ou corpus technique éprouvé à instancier. Le choix Maven/Gradle, la politique de wrapper et les versions de toolchain doivent être déterminés dans un chantier justifié avant de produire un skeleton concret.
+
+### Android — différé
+
+Le profil `610` définit la structure de responsabilité et les décisions Android, mais aucun template AGP/Gradle, manifest applicatif, matrice SDK ou projet réel n'existe dans PGR. Un skeleton Android serait prématuré avant ces pièces et avant la sélection explicite de sa composition avec Java/Gradle ou un autre stack réel.
+
+### Web, JNI, Tauri et autres familles absentes — différés
+
+Ces domaines ne possèdent pas encore tous leurs propriétaires normatifs et templates nécessaires. `0.0.4` ne crée pas de profils ou skeletons placeholders pour eux.
+
+## Contrat visé pour une skeleton specification
+
+La tranche de composition devra fixer un contrat commun minimal. Chaque skeleton doit au moins permettre d'identifier :
+
+```text
+applicabilité et objectif
+profils/règles sélectionnés
+fichiers à créer, copier ou adapter
+templates applicables et source de leurs choix
+décisions obligatoires propres au destinataire
+options et exceptions explicites
+ordre de composition
+validation initiale proportionnée
+éléments volontairement hors scope
+```
+
+Un skeleton reste une procédure Markdown. Il ne génère pas le projet, ne télécharge pas de dépendances, ne remplace pas les toolchains et ne fige pas l'architecture future. Après instanciation, le projet possède ses copies locales et ses décisions.
+
+Les règles communes de sélection et de composition doivent avoir un propriétaire normatif unique sous `docs/rules/`. Les spécifications concrètes vivront dans une collection documentaire dédiée créée seulement avec son premier contenu réel. Les fichiers techniques copiables restent sous `templates/` et leurs instructions d'adaptation sous `docs/templates/`.
+
+## Découpage prévisionnel de `0.0.4`
+
+### alpha.1 — audit de stable et cadrage
+
+Vérifier indépendamment `v0.0.3`, le rapport post-tag, les règles `200` à `610`, les cinq templates Rust/Cargo, les trois audits Markdown, les deux audits Rust facultatifs et la chaîne de deltas/histories. Inventorier les skeletons réellement justifiés et fixer le présent plan avant toute matérialisation importante.
+
+### alpha.2 — contrat de composition des skeletons
+
+Créer le propriétaire normatif des règles de sélection et de composition des skeletons, puis la collection documentaire des skeleton specifications avec son index. Définir la frontière entre règles copiées/adaptées, templates techniques, décisions propres au projet, overrides et validation. Réconcilier les index et l'architecture sans créer encore de domaine technologique supplémentaire.
+
+Le nom et le numéro exacts du document normatif seront choisis à l'application selon la responsabilité finale ; le plan ne transforme pas un chemin prévisionnel en règle déjà active.
+
+### alpha.3 — fondation de projet gouverné
+
+Matérialiser une première specification composable décrivant la baseline de gouvernance locale d'un projet utilisant PGR : version, règles sélectionnées, documentation minimale, workflow réellement retenu et validation initiale. Elle doit rester proportionnée et permettre d'omettre les collections ou artefacts sans contenu réel.
+
+Cette fondation n'est ni un framework ni une architecture applicative et ne doit pas recopier les deltas, histories ou décisions propres au dépôt PGR.
+
+### alpha.4 — skeleton Rust/Cargo workspace
+
+Matérialiser la première specialization technologique en composant la fondation gouvernée avec `500 + 510`, les cinq templates Rust/Cargo et les guides d'adaptation existants. Documenter les décisions destinataire avant copie et les audits facultatifs explicitement sélectionnés.
+
+La gate doit inclure une instanciation temporaire minimale ou une vérification équivalente lorsque la toolchain Rust est disponible, afin de distinguer la validité syntaxique des templates de leur adoption correcte. Cette preuve ne transforme pas PGR lui-même en workspace Rust.
+
+### beta.1 — réconciliation interne
+
+Vérifier ownership, liens, index, absence de duplication normative, non-universalisation des valeurs d'exemple, limites des audits et cohérence des deux premières specifications. Confirmer explicitement que Java/Android/Web/JNI/Tauri restent différés tant que leurs pièces requises manquent.
+
+Aucun chantier de réconciliation complète avec KSP ou Games n'entre ici : la roadmap réserve cette mission à `0.0.5`.
+
+La première gate `beta.1` a enregistré `FAIL` uniquement parce qu'une chaîne Python de contrôle contenait une apostrophe non échappée. `beta.1.fix.1` a corrigé la gate sans modifier de contenu vivant et a confirmé la réconciliation : owners distincts, trois documents skeletons seulement, valeurs Rust/Cargo adaptables, limites des audits explicites, cinq TOML valides et domaines différés toujours absents.
+
+### rc.1 — gate de release candidate
+
+Geler le scope, préparer l'entrée `0.0.4` du changelog et le prompt `005` de `0.0.5` si la trajectoire est confirmée. Rejouer les validations documentaires, tests et smokes réellement invalidés par la release.
+
+Le scope gelé comprend le contrat transversal `220-SKELETONS.md`, l'index de collection, la fondation gouvernée `001`, la spécialisation Rust/Cargo `002` et l'utilisation des cinq templates Rust/Cargo déjà présents. Aucun nouveau domaine technologique, générateur, template, audit ou règle normative n'entre en RC. La trajectoire `0.0.5` reste celle de la roadmap : réconciliation réelle de PGR avec `khadhroony-solana-project` et `sasedev-games`, à partir de baselines explicites qui devront être fournies à cette future session plutôt que déduites d'un état local implicite.
+
+### stable — 0.0.4
+
+La gate opérateur de `rc.1` est `PASS`. Le delta `rel.001` prépare mécaniquement la stable `0.0.4` : `VERSION`, présentation du dépôt et des index, statut de la roadmap, conversion de l'entrée candidate du changelog et clôture du présent plan comme référence historique. Aucun nouveau skeleton, profil, template, audit ou domaine technologique n'est ajouté pendant cette promotion.
+
+Le résultat réel de la gate pré-tag appartient à `history/0.0.4/rel.001.md`, produit après exécution opérateur. Le commit stable et le tag `v0.0.4` suivent uniquement un `PASS`. La vérification de l'archive effectivement publiée depuis Gitea et le rapport `pgr-0.0.4-publish.001-report.md` constituent ensuite une preuve post-tag séparée ; ils ne sont pas présumés par le delta ni par le history pré-tag.
+
+## Points de décision et stratégie de validation
+
+Un REPLAN devient nécessaire si la fondation gouvernée exige des templates génériques inexistants pour rester actionnable, si le contrat de composition duplique des règles existantes au lieu de les référencer, si le skeleton Rust impose une architecture plus étroite que le profil `510`, ou si l'instanciation minimale révèle qu'un template technique ne peut pas être adopté sans nouvelle décision normative.
+
+Les tranches documentaires utilisent les trois audits Markdown et les contrôles Git applicables. Toute modification des scripts ou de leurs contrats rejoue leurs tests ciblés. Toute modification d'un template Rust/Cargo vérifie sa syntaxe et, lorsqu'elle prétend à une instanciation fonctionnelle, une gate Cargo proportionnée dans un environnement temporaire. Aucun build Java/Android n'est demandé tant qu'aucun artefact concret de ces écosystèmes n'entre dans le scope.

docs/rules/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/000-README.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Index des règles PGR
 
@@ -13,6 +13,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, 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.
 - [`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.

docs/rules/220-SKELETONS.md

@@ -0,0 +1,123 @@
+<!-- file: docs/rules/220-SKELETONS.md -->
+<!-- version: 1 -->
+
+# Skeleton specification rules
+
+## Scope
+
+Ce document définit le contrat transversal des skeleton specifications PGR : applicabilité, sélection des règles et profils, composition de skeletons, usage des templates, décisions propres au projet, overrides, instanciation et validation initiale.
+
+Il ne définit pas les règles propres à une technologie. Les profils restent possédés par leurs documents normatifs, notamment le modèle de composition de [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md). Les règles de validation restent possédées par [`400-VALIDATION.md`](400-VALIDATION.md) et le workflow delta/history par [`210-WORKFLOW.md`](210-WORKFLOW.md).
+
+Les skeleton specifications concrètes vivent sous [`../skeletons/`](../skeletons/000-README.md).
+
+## Nature d'un skeleton
+
+Un skeleton PGR est une spécification Markdown procédurale permettant de construire une baseline locale cohérente à partir de règles, profils, templates et décisions explicites.
+
+Un skeleton MUST NOT devenir :
+
+- un générateur obligatoire de projet ;
+- une dépendance runtime ou build vers PGR ;
+- un nouveau propriétaire implicite de règles déjà possédées ailleurs ;
+- un moyen de figer une architecture au-delà du scope qu'il déclare ;
+- un catalogue de technologies ou de fichiers créés par anticipation.
+
+Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet.
+
+## Applicabilité
+
+Chaque skeleton MUST rendre explicites son objectif et les faits qui déterminent son applicabilité.
+
+L'applicabilité MUST reposer sur le besoin réel du projet : type de baseline recherchée, langage ou écosystème utilisé, plateforme ciblée, framework réellement présent ou autre propriété concrète du scope.
+
+Un skeleton MUST NOT être appliqué uniquement parce qu'il est fréquent, recommandé dans un autre projet ou disponible dans PGR.
+
+Un skeleton spécialisé MAY déclarer un autre skeleton comme fondation. Cette relation doit être explicite et ne rend pas les spécialisations sœurs applicables entre elles.
+
+## Contenu minimal d'une specification
+
+Une skeleton specification MUST permettre d'identifier sans ambiguïté :
+
+- son objectif et son applicabilité ;
+- les règles et profils sélectionnés ou requis ;
+- les autres skeletons dont elle dépend éventuellement pour sa composition ;
+- les fichiers à créer, copier, adapter ou omettre ;
+- les templates techniques utilisés et les décisions d'adaptation associées ;
+- les décisions obligatoires qui appartiennent au projet destinataire ;
+- les options, exceptions et overrides explicitement permis ;
+- l'ordre d'instanciation lorsque cet ordre est significatif ;
+- la validation initiale proportionnée ;
+- les éléments volontairement hors scope.
+
+La structure Markdown exacte MAY varier si ces responsabilités restent clairement séparées. PGR MUST NOT imposer des sections vides uniquement pour respecter un format cérémoniel.
+
+## Sélection des règles et profils
+
+Un skeleton sélectionne les owners normatifs applicables ; il ne redéfinit pas leur contenu.
+
+La sélection des profils MUST respecter l'applicabilité, la hiérarchie et la résolution définies dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).
+
+Lorsqu'une règle générale est déjà applicable sans spécialisation, le skeleton SHOULD la référencer plutôt que la recopier comme si elle lui appartenait. Lors de l'instanciation, le projet destinataire doit néanmoins disposer localement des règles nécessaires à son fonctionnement autonome, sous la forme documentaire réellement adaptée à son propre référentiel.
+
+Un skeleton MUST NOT sélectionner toute la bibliothèque PGR par défaut. Les profils ou familles sans rapport avec le projet restent absents.
+
+## Templates et artefacts techniques
+
+Un template reste un artefact technique copiable distinct du skeleton et de la règle qui justifie son usage.
+
+Lorsqu'un skeleton utilise un template, il MUST identifier le template source et les valeurs qui doivent être revues ou adaptées avant adoption. Une valeur d'exemple, un placeholder, une version de toolchain, un nom de crate, un chemin de build ou un seuil de lint présent dans un template MUST NOT devenir une valeur universelle par simple copie.
+
+Un skeleton MAY demander de copier un template tel quel seulement lorsque le contrat du template indique qu'aucune décision locale n'est requise pour le scope visé.
+
+Un skeleton MUST NOT télécharger des dépendances, installer des toolchains ou exécuter implicitement des commandes externes à la place du projet destinataire. Ces opérations peuvent faire partie d'une validation explicitement demandée lorsque l'environnement et le scope les justifient.
+
+## Décisions propres au projet
+
+Toute décision qui ne découle pas d'une règle applicable ou d'une contrainte technique établie reste une décision du projet destinataire.
+
+Le skeleton MUST distinguer une obligation normative d'une valeur d'exemple, d'un choix recommandé et d'une option libre lorsque cette distinction est nécessaire pour éviter une adoption accidentelle.
+
+Les décisions nécessaires à une baseline fonctionnelle MUST être résolues ou laissées comme entrées explicites avant que l'instanciation soit présentée comme terminée. Un choix encore ouvert MUST NOT être converti silencieusement en règle ou valeur par défaut arbitraire.
+
+Les décisions locales SHOULD être consignées dans les documents ou configurations qui les possèdent durablement dans le projet créé, et non uniquement dans une trace temporaire d'instanciation.
+
+## Composition de plusieurs skeletons
+
+La composition SHOULD partir de la fondation la plus générale explicitement requise, puis ajouter les spécialisations réellement applicables.
+
+Un skeleton spécialisé SHOULD référencer les responsabilités déjà couvertes par sa fondation plutôt que les recopier. Il MAY ajouter des fichiers, décisions, templates ou validations propres à son scope.
+
+L'ordre de composition ne crée aucune priorité normative implicite. Une règle plus spécifique ne remplace une règle plus générale que selon la hiérarchie normative, un profil applicable ou une exception explicitement documentée.
+
+Si deux skeletons applicables exigent des choix incompatibles sans relation de spécialisation ou override défini, l'instanciation MUST s'arrêter sur cette décision au lieu de choisir arbitrairement le dernier appliqué.
+
+PGR SHOULD NOT créer un skeleton composite pour chaque combinaison de technologies. Un skeleton composite n'est justifié que lorsqu'une interaction réelle possède des étapes, artefacts ou décisions qui ne peuvent pas être correctement possédés par les skeletons composants.
+
+## Overrides et exceptions
+
+Un override ou une exception MUST identifier la règle, le template, le choix ou l'étape concerné, son scope et sa raison.
+
+Un skeleton MAY prévoir des points d'override lorsqu'ils correspondent à une variabilité légitime du projet. Il MUST NOT utiliser cette possibilité pour affaiblir silencieusement une règle applicable ou masquer une incompatibilité entre profils.
+
+Une exception propre au projet est possédée par le projet destinataire après instanciation. Elle ne devient pas automatiquement une règle générale PGR.
+
+## Validation de l'instanciation
+
+Chaque skeleton MUST définir une validation initiale proportionnée à ce qu'il matérialise réellement.
+
+La validation SHOULD utiliser le mécanisme le plus fiable disponible : parseur ou build tool officiel, linter, audit structurel read-only, test ciblé ou revue humaine selon la propriété à prouver.
+
+Lorsqu'un skeleton prétend produire une baseline directement utilisable par une toolchain, une instanciation temporaire MAY être utilisée pour vérifier les fichiers copiés ou adaptés. Les ressources temporaires SHOULD être isolées et nettoyées après la gate.
+
+La réussite d'un audit structurel ne remplace pas une validation de toolchain lorsque le contrat à prouver appartient à cette toolchain. Inversement, PGR SHOULD NOT imposer un build coûteux lorsqu'une propriété purement documentaire ou structurelle suffit à la tranche.
+
+Une prévalidation réalisée lors de la préparation d'un delta ne remplace jamais la gate opérateur autoritaire définie par les règles de validation.
+
+## Évolution
+
+Une skeleton specification est un document vivant tant qu'elle reste la specification courante de son type de projet. Sa révision interne suit les règles documentaires PGR.
+
+Modifier un skeleton PGR n'altère pas rétroactivement les projets déjà instanciés. Une migration depuis une ancienne baseline est une décision explicite du projet concerné.
+
+PGR matérialise un nouveau skeleton uniquement lorsqu'un besoin réel, des owners normatifs suffisants et les artefacts nécessaires existent. Une technologie encore insuffisamment cadrée reste différée plutôt que représentée par un skeleton placeholder.

docs/skeletons/000-README.md

@@ -0,0 +1,25 @@
+<!-- file: docs/skeletons/000-README.md -->
+<!-- version: 3 -->
+
+# Index des skeleton specifications PGR
+
+Cette collection contient les recettes Markdown utilisées pour initialiser des baselines de projet ou composer plusieurs profils PGR sans transformer PGR en générateur.
+
+Le contrat normatif commun des skeletons appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). Le modèle de composition des profils reste défini par [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).
+
+## Rôle de la collection
+
+Chaque specification concrète doit décrire un besoin réel et actionnable. Elle sélectionne les owners normatifs et templates nécessaires, rend visibles les décisions propres au projet, définit l'ordre de composition utile et fournit une validation initiale proportionnée.
+
+Les fichiers techniques copiables ne vivent pas ici : ils restent sous `templates/`. Leurs guides d'adaptation restent sous `docs/templates/`. Les règles restent sous `docs/rules/`.
+
+Une specification peut se composer avec une fondation plus générale, mais la collection ne duplique pas artificiellement une recette pour chaque combinaison possible de technologies.
+
+## Specifications actives
+
+- [`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.
+
+Les familles Java/Android, Web, JNI, Tauri et autres domaines sans pièces suffisantes restent différées selon le plan [`../plans/004-V0_0_4_SKELETONS_PLAN.md`](../plans/004-V0_0_4_SKELETONS_PLAN.md).
+
+Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.

docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md

@@ -0,0 +1,154 @@
+<!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
+<!-- version: 1 -->
+
+# Skeleton — Project governance foundation
+
+## Objectif
+
+Cette specification décrit une fondation composable pour un projet qui choisit d'adopter la gouvernance PGR sans sélectionner encore de langage, plateforme, framework ou architecture applicative.
+
+Elle permet d'établir une baseline locale cohérente : identité de version, point d'entrée normatif, documentation réellement utile, workflow de changement effectivement retenu et validation initiale proportionnée.
+
+Le contrat commun des skeletons appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). La présente specification sélectionne et adapte les owners généraux utiles ; elle n'en devient pas propriétaire.
+
+## Applicabilité
+
+Appliquer cette fondation lorsqu'un dépôt ou release unit veut utiliser PGR comme source de gouvernance locale et qu'aucune specialization technologique n'est nécessaire pour définir cette base commune.
+
+Elle MAY servir de fondation à un skeleton spécialisé, qui ajoute ensuite uniquement les profils, templates, décisions et validations propres à son scope.
+
+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
+
+La fondation s'appuie sur les responsabilités PGR suivantes :
+
+```text
+docs/rules/200-GOVERNANCE.md
+    versioning, phases et discipline de changement
+
+docs/rules/210-WORKFLOW.md
+    plans, deltas, histories, commits de tranche et artefacts à la demande
+
+docs/rules/300-DOCUMENTATION.md
+    rôles documentaires, taxonomie, révisions et snapshots
+
+docs/rules/400-VALIDATION.md
+    preuves proportionnées, statuts de gate et autorité opérateur
+```
+
+`docs/rules/220-SKELETONS.md` gouverne l'instanciation elle-même. Il n'est pas automatiquement une règle à recopier dans le projet destinataire si ce projet ne maintient pas sa propre collection de skeletons.
+
+Aucun profil `500+` ou `600+` n'est sélectionné par cette fondation. Un skeleton spécialisé les ajoute seulement lorsqu'ils sont réellement applicables.
+
+## Décisions destinataire avant matérialisation
+
+Avant de considérer la fondation comme instanciée, résoudre explicitement les décisions suivantes :
+
+1. identifier le release unit gouverné et sa version SemVer courante ;
+2. décider si le projet utilise le fichier racine `VERSION` comme repère canonique simple ;
+3. identifier les règles PGR réellement reprises et les adaptations locales nécessaires ;
+4. déterminer quels documents vivants ont une responsabilité réelle dès la baseline ;
+5. déterminer quels artefacts du workflow PGR sont effectivement utilisés et à partir de quel état gouverné ;
+6. sélectionner les validations disponibles qui prouvent réellement cette baseline ;
+7. consigner toute exception ou divergence intentionnelle dans le propriétaire local approprié.
+
+Une décision non résolue MUST rester visible comme décision à prendre. Elle ne doit pas être remplacée par une valeur arbitraire provenant de PGR ou d'un autre projet.
+
+## Baseline locale à matérialiser
+
+### Point d'entrée normatif
+
+Le projet destinataire MUST disposer d'un point d'entrée normatif local clairement identifiable. Lorsqu'il adopte la convention PGR, ce point d'entrée est `RULES.md`.
+
+Ce document doit au minimum :
+
+- déclarer le scope qu'il gouverne ;
+- identifier les owners généraux ou spécialisés réellement applicables ;
+- expliquer la priorité ou la spécialisation locale lorsqu'une adaptation existe ;
+- renvoyer vers les documents détaillés au lieu de recopier leur contenu sans nécessité.
+
+Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable.
+
+### Version
+
+Le release unit MUST posséder une version SemVer courante explicite conformément au contrat local retenu.
+
+Si le fichier racine `VERSION` est choisi, l'instanciation doit le créer ou l'adapter selon [`../rules/200-GOVERNANCE.md`](../rules/200-GOVERNANCE.md). Si l'écosystème possède un autre owner canonique, la relation avec `VERSION` doit être décidée explicitement plutôt que dupliquée par défaut.
+
+La valeur de version initiale appartient au projet destinataire. Cette specification ne fournit pas de numéro universel.
+
+### Documentation minimale
+
+`README.md` SHOULD fournir l'onboarding et les points d'entrée de premier niveau du projet.
+
+Créer `docs/000-README.md` uniquement si une documentation structurée sous `docs/` existe réellement. Créer ensuite uniquement les collections possédant un premier contenu utile. Une collection vide ou un document placeholder n'est pas requis par cette fondation.
+
+Selon la réalité du projet :
+
+- `ROADMAP.md` est utile lorsqu'une trajectoire macro doit être rendue explicite ;
+- `CHANGELOG.md` est utile lorsque des changements de release doivent être communiqués aux utilisateurs ou intégrateurs ;
+- `docs/objectives/` est utile lorsqu'une mission durable, des contraintes ou non-objectifs méritent un owner distinct ;
+- `docs/architecture/` est utile lorsqu'un état architectural ou un profil local doit être possédé durablement ;
+- `docs/validation/` est utile lorsqu'une matrice ou un contrat de preuve mérite un document séparé.
+
+Ne pas créer ces fichiers uniquement pour reproduire l'arborescence du dépôt PGR.
+
+### Workflow retenu
+
+Si le projet adopte le workflow de tranches PGR, il doit préserver la séquence définie par [`../rules/210-WORKFLOW.md`](../rules/210-WORKFLOW.md) : intention prospective dans le delta, gate réelle, preuve rétrospective dans le history, puis commit de tranche avant application du delta suivant.
+
+Les répertoires `deltas/`, `history/`, `prompts/`, `handoffs/` et `manifests/` sont créés à la demande lorsqu'un artefact réel les justifie. Ils ne constituent pas un layout obligatoire à précréer.
+
+Un projet qui n'adopte qu'une partie du workflow PGR doit l'indiquer dans ses règles locales et ne pas présenter les artefacts omis comme s'ils étaient encore obligatoires.
+
+### Validation initiale
+
+La validation de la fondation doit prouver seulement les propriétés réellement matérialisées. Elle SHOULD combiner selon le scope :
+
+```text
+CHECK  version courante conforme au mécanisme choisi
+CHECK  git diff --check ou équivalent du VCS retenu
+AUDIT  chemins et rôles documentaires réellement créés
+AUDIT  liens locaux principaux si la navigation Markdown a été modifiée
+AUDIT  owners sélectionnés et exceptions locales explicites
+REVIEW absence de collections, profils ou placeholders non justifiés
+```
+
+Si le projet possède déjà des audits fiables pour ses headers, liens, structure ou règles, ils MAY être ajoutés. Cette fondation n'impose pas de copier les scripts du dépôt PGR sans décision explicite de réutilisation.
+
+La prévalidation qui accompagne une instanciation ou un delta ne remplace pas la gate opérateur autoritaire du projet destinataire.
+
+## Ordre de composition
+
+Cette fondation SHOULD être appliquée avant une specialization qui la déclare comme base.
+
+Une specialization technologique peut ensuite :
+
+- sélectionner ses familles et profils applicables ;
+- copier ou adapter les templates techniques correspondants ;
+- ajouter ses décisions spécifiques ;
+- étendre la validation initiale avec la toolchain réellement concernée.
+
+Elle MUST NOT redéfinir les responsabilités générales déjà possédées par la fondation sauf specialization ou override explicitement justifié.
+
+## Overrides et exceptions
+
+Un projet MAY adapter la structure documentaire, le mécanisme de version, le VCS, le workflow ou une convention PGR lorsqu'une contrainte réelle le justifie et que l'owner local reste clair.
+
+Une exception doit identifier son scope et sa raison. Elle ne devient pas une règle générale PGR et ne doit pas être masquée par la simple copie d'un fichier provenant de PGR.
+
+## Hors scope
+
+Cette fondation ne définit pas :
+
+- l'architecture applicative ou les crates/modules/packages du produit ;
+- un langage, une plateforme, un framework ou une toolchain ;
+- des noms de package, versions de dépendances ou chemins de build ;
+- des templates techniques génériques inexistants ;
+- un CI/CD universel ;
+- une politique de branching universelle ;
+- une obligation de recopier la structure complète du dépôt PGR ;
+- la migration rétroactive des anciennes releases ou anciens commits du projet destinataire.
+
+Les spécialisations futures doivent rester indépendantes et composables au-dessus de cette fondation.

docs/skeletons/002-RUST_CARGO_WORKSPACE.md

@@ -0,0 +1,206 @@
+<!-- file: docs/skeletons/002-RUST_CARGO_WORKSPACE.md -->
+<!-- version: 1 -->
+
+# Skeleton — Rust/Cargo workspace
+
+## Objectif
+
+Cette specification décrit la specialization Rust/Cargo d'un projet gouverné par PGR lorsque plusieurs packages Rust partagent réellement une même unité de release, une politique Cargo commune ou une validation de workspace commune.
+
+Elle se compose avec [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md), sélectionne les profils [`../rules/500-LANGUAGES.md`](../rules/500-LANGUAGES.md) et [`../rules/510-RUST_CARGO.md`](../rules/510-RUST_CARGO.md), puis utilise les templates et guides Rust/Cargo déjà présents dans PGR. Le contrat transversal des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md).
+
+Cette specification ne transforme pas PGR en générateur Cargo et ne crée aucune dépendance build ou runtime vers le dépôt PGR après instanciation.
+
+## Applicabilité et composition
+
+Appliquer ce skeleton lorsqu'un projet utilise Rust avec Cargo et qu'un workspace représente réellement son unité de gouvernance ou de release.
+
+La composition normale est :
+
+```text
+001-PROJECT_GOVERNANCE_FOUNDATION
+    ↓
+500-LANGUAGES
+    ↓
+510-RUST_CARGO
+    ↓
+002-RUST_CARGO_WORKSPACE
+```
+
+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.
+
+## 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 :
+
+```text
+docs/rules/500-LANGUAGES.md
+    contrat commun langage/écosystème
+
+docs/rules/510-RUST_CARGO.md
+    workspace, manifests, dépendances, lints, safety, formatage et validation Cargo
+
+docs/templates/001-RUST_CARGO_TOOLING.md
+    adaptation de rustfmt.toml, clippy.toml et .cargo/config.toml
+
+docs/templates/002-CARGO_MANIFESTS.md
+    adaptation du manifest workspace et du manifest membre
+```
+
+Les cinq artefacts techniques copiables sélectionnés sont :
+
+```text
+templates/rust-cargo/rustfmt.toml
+templates/rust-cargo/clippy.toml
+templates/rust-cargo/.cargo/config.toml
+templates/rust-cargo/Cargo.toml
+templates/rust-cargo/crates/project-core-lib/Cargo.toml
+```
+
+[`../validation/002-RUST_STYLE_AUDITS.md`](../validation/002-RUST_STYLE_AUDITS.md) est seulement une option supplémentaire. Les scripts `audit_rust_blank_lines.py`, `audit_rust_const_blocks.py` et `_rust_audit_common.py` ne sont copiés que si le projet choisit explicitement les conventions correspondantes et sait quels fichiers Rust doivent être audités.
+
+## Décisions destinataire avant copie
+
+Avant de considérer la specialization comme instanciée, résoudre explicitement au minimum :
+
+1. le release unit gouverné et la relation entre son `VERSION` et `[workspace.package].version` ;
+2. la liste réelle des packages membres, leurs noms, leurs rôles et leurs chemins ;
+3. l'édition Rust, le resolver Cargo et la toolchain stable compatible ;
+4. la politique de publication et les métadonnées réelles communes (`license`, `repository`, `authors`) lorsqu'elles existent ;
+5. les dépendances réellement partagées, leurs contraintes de version et les features qui doivent rester locales à chaque membre ;
+6. la politique de versionnement de `Cargo.lock` adaptée au type de produit ;
+7. les niveaux de lints hérités, les éventuelles exceptions locales et tout besoin réel d'`unsafe` dans un scope étroit ;
+8. les paramètres `rustfmt.toml` et `clippy.toml` à conserver ou adapter ;
+9. l'emplacement des artefacts Cargo et l'identifiant unique utilisé dans `.cargo/config.toml` si cette politique externe au dépôt est retenue ;
+10. les audits de style Rust facultatifs réellement adoptés et leur corpus exact ;
+11. les validations Cargo réellement nécessaires au code et aux manifests créés.
+
+Les valeurs `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build présents dans les templates sont des exemples ou baselines à revoir. Ils ne deviennent jamais des valeurs universelles par simple copie.
+
+## Matérialisation du workspace
+
+### Fondation gouvernée
+
+Appliquer d'abord la fondation `001` et résoudre ses décisions générales. Ne recopier ni le workflow ni la structure documentaire complète de PGR lorsqu'ils ne sont pas nécessaires au projet destinataire.
+
+La version canonique du release unit doit être décidée avant d'adapter les manifests. Pour un train de release Cargo unique, `[workspace.package].version` reflète cette version selon `510-RUST_CARGO.md`.
+
+### Manifest workspace
+
+Copier `templates/rust-cargo/Cargo.toml` vers `Cargo.toml`, puis :
+
+- adapter le header `# file:` et démarrer la révision locale selon la convention documentaire retenue ;
+- remplacer `members` par les packages réellement présents ;
+- remplacer la version d'exemple par la version du release unit lorsque le workspace partage une seule release ;
+- aligner `edition` et `resolver` sur la toolchain réellement choisie ;
+- décider explicitement `publish` et les métadonnées communes ;
+- ajouter sous `[workspace.dependencies]` uniquement les dépendances réellement partagées ;
+- conserver, adapter ou documenter les niveaux de lints selon le profil local retenu.
+
+Le projet ne doit pas remplir les champs manquants avec des identités fictives provenant de PGR, KSP ou Games.
+
+### Packages membres
+
+Pour chaque crate réellement nécessaire, utiliser `templates/rust-cargo/crates/project-core-lib/Cargo.toml` comme exemple de manifest membre puis adapter son chemin et son nom.
+
+`project-core-lib` n'est pas un nom de crate imposé. Une crate bibliothèque, binaire ou spécialisée doit conserver le layout et les héritages qui correspondent à son rôle réel.
+
+Lorsque le membre hérite de la politique commune, `version.workspace = true`, `edition.workspace = true`, `publish.workspace = true` et `[lints] workspace = true` restent cohérents. Une exception locale, notamment de lint ou de safety, doit suivre le contrat de `510-RUST_CARGO.md` et ne pas affaiblir silencieusement les autres membres.
+
+Le code source minimal requis par Cargo appartient au projet destinataire. PGR ne fournit pas de `src/lib.rs` ou `src/main.rs` universel, car leur contenu dépend du rôle réel de la crate.
+
+### Outillage Rust/Cargo
+
+Copier et adapter :
+
+```text
+rustfmt.toml
+clippy.toml
+.cargo/config.toml
+```
+
+Suivre [`../templates/001-RUST_CARGO_TOOLING.md`](../templates/001-RUST_CARGO_TOOLING.md) pour leurs décisions d'adaptation.
+
+L'édition de `rustfmt.toml` doit rester cohérente avec le workspace. Les seuils de `clippy.toml` doivent être revus au regard des API réelles. Dans `.cargo/config.toml`, remplacer `project-name` ou choisir un autre emplacement d'artefacts ; ne pas copier un chemin machine ou un identifiant appartenant à un autre projet.
+
+### Cargo.lock
+
+Décider explicitement si `Cargo.lock` est versionné selon le type de produit, le mode de publication et le besoin de reproductibilité. La présence ou l'absence du lockfile dans un projet source historique ne constitue pas une règle suffisante pour le nouveau workspace.
+
+### Audits de style facultatifs
+
+Si le projet adopte les conventions documentées dans [`../validation/002-RUST_STYLE_AUDITS.md`](../validation/002-RUST_STYLE_AUDITS.md), copier les trois scripts concernés et adapter leurs headers à leurs chemins locaux.
+
+La sélection des fichiers doit rester explicite. En particulier, l'audit des blocs de constantes ne doit jamais réordonner une table de protocole, une séquence de migrations ou toute autre structure dont l'ordre possède une sémantique propre.
+
+Ne pas copier ces scripts uniquement parce qu'ils existent dans PGR.
+
+## Validation initiale
+
+Une instanciation minimale doit d'abord prouver que les manifests adaptés décrivent bien le workspace voulu, puis que les outils Rust/Cargo retenus acceptent la baseline réelle.
+
+Lorsque la toolchain est disponible et que du code source minimal ou réel existe, la séquence normale comprend :
+
+```bash
+cargo metadata --format-version 1 --no-deps
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Ajouter des tests ciblés pour les crates qui possèdent déjà un comportement à vérifier. Un `cargo build` n'est nécessaire que lorsqu'un artefact de build doit réellement être produit.
+
+Si les audits de style facultatifs ont été sélectionnés, les exécuter après le formatage sur les seuls chemins concernés.
+
+La validation doit aussi confirmer :
+
+```text
+CHECK  VERSION et workspace.package.version cohérents pour un train de release unique
+CHECK  aucun placeholder project-name/project-core-lib non résolu dans les fichiers adoptés
+CHECK  édition Rust cohérente entre Cargo.toml et rustfmt.toml
+CHECK  membres du workspace existants et correctement nommés
+CHECK  politique Cargo.lock explicitement décidée
+CHECK  artefacts Cargo hors des livraisons source selon la politique locale
+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.
+
+Une prévalidation PGR ou générateur ne remplace jamais la gate opérateur autoritaire du projet destinataire.
+
+## Ordre de composition et extensions
+
+La specialization Rust/Cargo doit être appliquée après `001` lorsqu'elle l'utilise comme fondation. Les profils plateforme ou framework viennent ensuite uniquement s'ils sont applicables.
+
+Une specialization plus précise peut :
+
+- ajouter des packages ou cibles spécifiques ;
+- imposer une matrice de toolchain ou de SDK ;
+- raffiner la politique d'artefacts ou de lockfile ;
+- ajouter des features, dépendances ou validations propres à son scope ;
+- définir une exception locale de safety strictement justifiée.
+
+Elle ne doit pas réécrire les règles générales Cargo ou inventer un nouveau workspace composite si les owners existants suffisent.
+
+## Overrides et exceptions
+
+Toute divergence par rapport aux templates ou au profil `510` doit identifier le choix concerné, son scope et sa raison lorsqu'elle affecte le contrat durable du projet.
+
+Un projet peut notamment choisir un layout sans `crates/`, un autre chemin d'artefacts, une autre largeur Rustfmt, une politique de lockfile différente, des seuils Clippy différents ou une crate à lints locaux. Ces choix restent locaux et ne modifient pas les defaults PGR pour les autres projets.
+
+## Hors scope
+
+Cette specification ne définit pas :
+
+- un nom universel de workspace ou de crate ;
+- une version Rust ou Cargo exacte à pinner sans justification ;
+- une liste universelle de dépendances ou features ;
+- une politique `Cargo.lock` identique pour bibliothèques et applications ;
+- une architecture applicative au-delà du workspace Cargo ;
+- une plateforme, un framework, WASM, Android, Tauri ou une FFI ;
+- un CI/CD, packaging ou mécanisme de publication universel ;
+- une obligation de copier les audits Rust facultatifs ;
+- un `src/lib.rs` ou `src/main.rs` générique sans rôle réel.
+
+Les spécialisations futures doivent rester composables au-dessus de ce skeleton plutôt que modifier rétroactivement son scope.

history/0.0.4/alpha.1.md

@@ -0,0 +1,76 @@
+<!-- file: history/0.0.4/alpha.1.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-alpha.1 — audit de baseline et cadrage des skeletons
+
+## Statut
+
+PASS
+
+La gate de `0.0.4-alpha.1` exécutée par l'opérateur le `2026-09-24` valide la reprise depuis la stable `0.0.3`, le cadrage des premières skeleton specifications et le plan actif de `0.0.4`. Les contrôles mécaniques demandés sont propres et le scope Git observé correspond exactement au delta.
+
+## Baseline et version
+
+La tranche a été appliquée sur l'état stable `0.0.3` contrôlé pendant le cadrage depuis l'archive `pgr-v0.0.3.zip` et le rapport post-tag externe `pgr-0.0.3-publish.001-report.md` déclaré `PASS`.
+
+La version contrôlée après application est :
+
+```text
+0.0.4-alpha.1
+```
+
+Le plan `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` et le delta `deltas/0.0.4/alpha.1.md` sont présents ; `history/0.0.4/alpha.1.md` était absent pendant la gate. Les révisions attendues de `README.md` et `docs/000-README.md` sont respectivement `7` et `5`, et les deux documents référencent le plan actif.
+
+## Validation opérateur observée
+
+L'opérateur a fourni les sorties du `2026-09-24` depuis `~/Projects/pgr`. Le contrôle de `VERSION` a été exécuté à `13:48:46`, puis les autres contrôles et validations à `13:53:25`–`13:53:26`.
+
+La suite Python globale a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.223s
+
+OK
+```
+
+Les trois audits documentaires affichent :
+
+```text
+Markdown header audit: clean (101 file(s))
+Markdown table audit: clean (3 table(s), 101 file(s))
+Markdown link audit: clean (81 local link(s), 101 file(s))
+```
+
+Le contrôle structurel de la baseline affiche :
+
+```text
+Baseline structural audit: clean (34 prior delta/history pairs, 10/10 histories 0.0.3 PASS, 5 TOML parsed)
+```
+
+Il confirme notamment l'appariement des `12` deltas/histories de `0.0.1`, des `12` de `0.0.2` et des `10` de `0.0.3`, le statut `PASS` des dix histories `0.0.3`, la présence des trois scripts d'audit Rust attendus et le parsing des cinq fichiers TOML du template Rust/Cargo.
+
+`git diff --check` et `git diff --cached --check` n'ont affiché aucun diagnostic. Après ajout des fichiers du delta, le statut indexé transmis est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.0.4/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+La transcription du terminal intercale un fragment du heredoc Python avec le début de la sortie `unittest`. Les quinze cas individuels, le résumé final `OK`, les trois audits documentaires, le contrôle structurel et le statut Git restent néanmoins identifiables et ne signalent aucun échec.
+
+## Revue de cadrage
+
+La revue du contenu livré confirme que le plan distingue bien les prévisions des règles déjà actives : le contrat commun des skeletons est présenté comme une cible à fixer dans `alpha.2`, et aucun chemin prévisionnel n'est transformé en propriétaire normatif avant sa création effective.
+
+Les valeurs Rust/Cargo citées dans le plan restent explicitement des exemples ou décisions destinataire à adapter, notamment `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build. Aucun de ces choix n'est promu en valeur universelle.
+
+Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles sans pièces suffisantes restent explicitement différés. Aucun skeleton concret, profil supplémentaire, template ou artefact technologique de ces domaines n'est matérialisé dans `alpha.1`.
+
+## Transition
+
+Appliquer le présent history puis committer `0.0.4-alpha.1` avant tout delta `alpha.2`. Le commit futur n'est pas attesté par les sorties fournies.
+
+Après ce commit, la tranche suivante est `0.0.4-alpha.2` et doit rester limitée au contrat de sélection et de composition des skeletons, à son propriétaire normatif et à l'index de la collection documentaire correspondante, conformément au plan actif.

history/0.0.4/alpha.2.md

@@ -0,0 +1,103 @@
+<!-- file: history/0.0.4/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-alpha.2 — contrat de composition des skeletons
+
+## Statut
+
+PASS
+
+La gate de `0.0.4-alpha.2` exécutée par l'opérateur le `2026-09-24` valide le propriétaire normatif transversal des skeleton specifications, l'activation de leur collection documentaire et la réconciliation des index et documents d'architecture concernés. Les contrôles mécaniques demandés sont propres et le scope Git observé correspond exactement au delta.
+
+## Baseline et version
+
+La tranche a été appliquée après le commit opérateur `bf306da` de `0.0.4-alpha.1`, qui contenait `history/0.0.4/alpha.1.md` avec statut `PASS` et avait été poussé sur `origin/master`.
+
+La version contrôlée après application est :
+
+```text
+0.0.4-alpha.2
+```
+
+`history/0.0.4/alpha.1.md`, `deltas/0.0.4/alpha.2.md`, `docs/rules/220-SKELETONS.md` et `docs/skeletons/000-README.md` sont présents ; `history/0.0.4/alpha.2.md` était absent pendant la gate.
+
+Les skeleton specifications concrètes prévues pour les tranches suivantes étaient bien absentes :
+
+```text
+docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+```
+
+## Validation opérateur observée
+
+L'opérateur a fourni les sorties du `2026-09-24` depuis `~/Projects/pgr`, à `14:15:19`–`14:15:20`.
+
+Les révisions documentaires attendues ont été confirmées :
+
+```text
+README.md                                              version 8
+RULES.md                                               version 10
+docs/000-README.md                                     version 6
+docs/architecture/002-GOVERNANCE_ARCHITECTURE.md      version 3
+docs/architecture/003-RULE_PROFILE_MODEL.md            version 3
+docs/rules/000-README.md                               version 11
+docs/rules/220-SKELETONS.md                            version 1
+docs/skeletons/000-README.md                           version 1
+```
+
+Les références attendues vers `docs/rules/220-SKELETONS.md` et `docs/skeletons/` sont présentes dans les points d'entrée, l'index normatif et les deux documents d'architecture concernés.
+
+La suite Python globale a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.256s
+
+OK
+```
+
+Les trois audits documentaires affichent :
+
+```text
+Markdown header audit: clean (105 file(s))
+Markdown table audit: clean (3 table(s), 105 file(s))
+Markdown link audit: clean (97 local link(s), 105 file(s))
+```
+
+Le contrôle structurel spécifique affiche :
+
+```text
+Skeleton contract audit: clean (alpha.1 PASS baseline, alpha.2 contract/index only)
+```
+
+Il confirme notamment que `history/0.0.4/alpha.1.md` est le seul history `0.0.4` présent pendant la gate, qu'il est `PASS`, que la collection `docs/skeletons/` ne contient encore que son index et que les huit responsabilités prévues du contrat `220` sont présentes.
+
+`git diff --check` et `git diff --cached --check` n'ont affiché aucun diagnostic. Après ajout des fichiers du delta, le statut indexé transmis est exactement :
+
+```text
+M  README.md
+M  RULES.md
+M  VERSION
+A  deltas/0.0.4/alpha.2.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/architecture/003-RULE_PROFILE_MODEL.md
+M  docs/rules/000-README.md
+A  docs/rules/220-SKELETONS.md
+A  docs/skeletons/000-README.md
+```
+
+La transcription du terminal intercale à deux endroits des fragments de commandes/heredoc avec la sortie de `unittest`. Les quinze cas individuels, le résumé final `OK`, les audits documentaires, le contrôle structurel et le statut Git restent néanmoins identifiables et ne signalent aucun échec.
+
+## Revue de scope
+
+La tranche reste conforme au plan `0.0.4` : `docs/rules/220-SKELETONS.md` possède le contrat transversal de sélection et composition, tandis que `docs/architecture/003-RULE_PROFILE_MODEL.md` conserve la propriété de la hiérarchie et de la résolution des profils.
+
+La collection `docs/skeletons/` est réellement activée par son index mais ne contient aucun placeholder de specialization. Aucun skeleton de fondation, Rust/Cargo, Java/Android, Web, JNI, Tauri ou autre domaine technologique n'a été matérialisé dans `alpha.2`.
+
+## Transition
+
+Appliquer le présent history puis committer `0.0.4-alpha.2` avant d'appliquer le delta `0.0.4-alpha.3`.
+
+Le history `alpha.2` et le delta `alpha.3` peuvent être livrés dans le même échange sous deux archives distinctes. Cette livraison simultanée ne change pas l'ordre d'application : le delta suivant MUST rester absent du dépôt jusqu'au commit de la tranche `alpha.2`.
+
+La tranche suivante est `0.0.4-alpha.3` et doit rester limitée à la première skeleton specification composable de fondation de projet gouverné, sans specialization technologique.

history/0.0.4/alpha.3.md

@@ -0,0 +1,96 @@
+<!-- file: history/0.0.4/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-alpha.3 — fondation de projet gouverné
+
+## Statut
+
+PASS
+
+La gate de `0.0.4-alpha.3` exécutée par l'opérateur le `2026-09-24` valide la première skeleton specification concrète de PGR : une fondation composable de gouvernance locale sans specialization technologique. Les contrôles mécaniques demandés sont propres et le scope Git observé correspond exactement au delta.
+
+## Baseline et version
+
+La tranche a été appliquée après le commit opérateur `7408616` de `0.0.4-alpha.2`, qui contenait `history/0.0.4/alpha.2.md` avec statut `PASS` et avait été poussé sur `origin/master`.
+
+La version contrôlée après application est :
+
+```text
+0.0.4-alpha.3
+```
+
+`history/0.0.4/alpha.2.md`, `deltas/0.0.4/alpha.3.md` et `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` sont présents ; `history/0.0.4/alpha.3.md` était absent pendant la gate.
+
+Le skeleton technologique suivant était bien absent :
+
+```text
+docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+```
+
+## Validation opérateur observée
+
+L'opérateur a fourni les sorties du `2026-09-24` depuis `~/Projects/pgr`, à `14:30:21`–`14:31:25`.
+
+Les révisions documentaires attendues ont été confirmées :
+
+```text
+README.md                                                   version 9
+docs/000-README.md                                          version 7
+docs/skeletons/000-README.md                                version 2
+docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md        version 1
+```
+
+Les références attendues vers `001-PROJECT_GOVERNANCE_FOUNDATION.md` sont présentes dans `README.md`, `docs/000-README.md` et l'index `docs/skeletons/000-README.md`.
+
+La suite Python globale a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.229s
+
+OK
+```
+
+Les trois audits documentaires affichent :
+
+```text
+Markdown header audit: clean (108 file(s))
+Markdown table audit: clean (3 table(s), 108 file(s))
+Markdown link audit: clean (103 local link(s), 108 file(s))
+```
+
+Le contrôle structurel spécifique affiche :
+
+```text
+Governance foundation audit: clean (alpha.1/alpha.2 PASS baseline, one concrete non-technological skeleton)
+```
+
+Il confirme notamment que les seuls histories `0.0.4` présents pendant la gate étaient `alpha.1.md` et `alpha.2.md`, tous deux `PASS`, que la collection des skeletons contenait uniquement son index et la fondation `001`, et que les sections et owners généraux attendus étaient présents.
+
+`git diff --check` et `git diff --cached --check` n'ont affiché aucun diagnostic. Après ajout des fichiers du delta, le statut indexé transmis est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.0.4/alpha.3.md
+M  docs/000-README.md
+M  docs/skeletons/000-README.md
+A  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+```
+
+La transcription du terminal intercale des fragments de commandes/heredoc avec la sortie de `unittest`. Les quinze cas individuels, le résumé final `OK`, les audits documentaires, le contrôle structurel et le statut Git restent néanmoins identifiables et ne signalent aucun échec.
+
+## Revue de scope
+
+La fondation reste une procédure composable et non un template ou générateur implicite. Elle sélectionne uniquement les owners généraux `200`, `210`, `300` et `400`, conserve `220` comme contrat d'instanciation et ne sélectionne aucun profil `500+` ou `600+` par défaut.
+
+Les documents et répertoires sont créés à la demande selon un contenu réel ; aucune copie exhaustive du layout PGR n'est imposée. Les décisions destinataire restent explicites et aucune valeur d'exemple technologique n'est introduite dans cette tranche.
+
+L'ordre de composition permet à une specialization telle que Rust/Cargo d'ajouter ses profils, templates et validations sans redéfinir les responsabilités générales de la fondation.
+
+## Transition
+
+Appliquer le présent history puis committer `0.0.4-alpha.3` avant d'appliquer le delta `0.0.4-alpha.4`.
+
+Le history `alpha.3` et le delta `alpha.4` peuvent être livrés dans le même échange sous deux archives distinctes. Cette livraison simultanée ne change pas l'ordre d'application : le delta suivant MUST rester absent du dépôt jusqu'au commit de la tranche `alpha.3`.
+
+La tranche suivante est `0.0.4-alpha.4` et doit rester limitée au skeleton Rust/Cargo workspace, à sa composition avec la fondation `001`, aux cinq templates Rust/Cargo existants, aux décisions destinataire et à une validation d'instanciation proportionnée.

history/0.0.4/alpha.4.fix.1.md

@@ -0,0 +1,117 @@
+<!-- file: history/0.0.4/alpha.4.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-alpha.4.fix.1 — correction du smoke Rust/Cargo
+
+## Statut
+
+PASS
+
+La gate de `0.0.4-alpha.4.fix.1` exécutée par l'opérateur le `2026-09-24` valide la correction locale du smoke d'instanciation Rust/Cargo. Le `FAIL` historique de `alpha.4` reste inchangé ; le fix prouve que l'adaptation temporaire élimine désormais les placeholders avant l'exécution de la toolchain.
+
+## Baseline et version
+
+La tranche `0.0.4-alpha.4` a été committée et poussée sous le commit observé :
+
+```text
+c0735d1
+```
+
+Ce commit contient `history/0.0.4/alpha.4.md` avec statut `FAIL`.
+
+La version contrôlée après application du correctif est :
+
+```text
+0.0.4-alpha.4.fix.1
+```
+
+Les deltas `alpha.4.md` et `alpha.4.fix.1.md`, le history `alpha.4.md` et le skeleton `docs/skeletons/002-RUST_CARGO_WORKSPACE.md` sont présents. `history/0.0.4/alpha.4.fix.1.md` était absent pendant la gate.
+
+## Validation opérateur observée
+
+La suite Python globale a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.225s
+
+OK
+```
+
+Les trois audits Markdown ont réussi :
+
+```text
+Markdown header audit: clean (113 file(s))
+Markdown table audit: clean (3 table(s), 113 file(s))
+Markdown link audit: clean (113 local link(s), 113 file(s))
+```
+
+Le contrôle structurel du correctif a affiché :
+
+```text
+Rust/Cargo fix audit: clean (alpha.4 FAIL recorded, skeleton/templates unchanged)
+```
+
+Il confirme les histories `alpha.1`, `alpha.2` et `alpha.3` en `PASS`, `alpha.4` en `FAIL`, les trois fichiers de skeleton attendus et le parsing TOML des cinq templates Rust/Cargo sans modification de ces artefacts.
+
+La toolchain opérateur observée est :
+
+```text
+cargo 1.94.1 (29ea6fb6a 2026-03-24)
+rustc 1.94.1 (e408947bf 2026-03-25)
+rustfmt 1.8.0-stable (e408947bfd 2026-03-25)
+clippy 0.1.94 (e408947bfd 2026-03-25)
+```
+
+La procédure temporaire corrigée a remplacé le commentaire de guidance de `.cargo/config.toml` en plus des chemins et autres placeholders, puis a affiché :
+
+```text
+Temporary Rust/Cargo template adaptation: clean
+```
+
+Aucun `project-name` ni `project-core-lib` ne subsiste donc dans les fichiers adoptés de la fixture temporaire avant la validation Cargo.
+
+La séquence suivante a ensuite été exécutée dans le workspace temporaire :
+
+```text
+cargo metadata --format-version 1 --no-deps
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+Aucun diagnostic d'échec n'a été transmis pour `cargo metadata` ou `cargo fmt`. `cargo check` et `cargo clippy` ont tous deux terminé avec succès pour :
+
+```text
+smoke-core-lib v1.2.3
+```
+
+Le workspace temporaire a ensuite été supprimé et le trap désarmé.
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le scope Git observé avant le présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/alpha.4.fix.1.md
+```
+
+La transcription du terminal contient quelques fragments de heredoc intercalés avec la sortie des tests ; les résultats finaux des commandes, audits, contrôles structurels et du scope Git restent toutefois identifiables et cohérents.
+
+## Résultat du correctif
+
+Le défaut de `alpha.4` appartenait uniquement à la fixture de validation et non aux règles, au skeleton `002` ou aux cinq templates distribués. `alpha.4.fix.1` corrige ce défaut sans modifier ces artefacts.
+
+La preuve d'instanciation est désormais complète pour le scope prévu : adaptation des placeholders, parsing/metadata Cargo, formatage, compilation de vérification et Clippy avec `-D warnings` sur une crate minimale.
+
+Aucun REPLAN n'est requis.
+
+## Transition
+
+Appliquer le présent history puis committer et pousser `0.0.4-alpha.4.fix.1` avant d'appliquer le delta suivant.
+
+La tranche suivante prévue par le plan est :
+
+```text
+0.0.4-beta.1
+```
+
+Elle doit rester une réconciliation interne : ownership, liens/index, absence de duplication normative, non-universalisation des valeurs d'exemple, limites des audits et confirmation des spécialisations différées. Elle ne doit pas créer de nouveau skeleton ou template sans défaut réel découvert pendant cette revue.

history/0.0.4/alpha.4.md

@@ -0,0 +1,142 @@
+<!-- file: history/0.0.4/alpha.4.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-alpha.4 — skeleton Rust/Cargo workspace
+
+## Statut
+
+FAIL
+
+La tranche `0.0.4-alpha.4` n'est pas enregistrée `PASS` telle quelle.
+
+Le contenu documentaire, les audits PGR et l'exécution réelle de Cargo sont cohérents, mais une assertion obligatoire de la gate d'instanciation a échoué : après adaptation du template `.cargo/config.toml`, le commentaire de guidance conservait encore le placeholder littéral `project-name`.
+
+## Baseline
+
+La tranche précédente `0.0.4-alpha.3` a été committée et poussée sous le commit observé :
+
+```text
+5471ea6
+```
+
+Version contrôlée après application de `alpha.4` :
+
+```text
+0.0.4-alpha.4
+```
+
+Les fichiers attendus sont présents et `history/0.0.4/alpha.4.md` était absent avant cette validation.
+
+## Contrôles réussis observés
+
+Les `15` tests Python ont tous réussi :
+
+```text
+Ran 15 tests in 0.251s
+OK
+```
+
+Les audits Markdown ont réussi :
+
+```text
+Markdown header audit: clean (111 file(s))
+Markdown table audit: clean (3 table(s), 111 file(s))
+Markdown link audit: clean (113 local link(s), 111 file(s))
+```
+
+L'audit structurel du skeleton Rust/Cargo a également réussi :
+
+```text
+Rust/Cargo skeleton audit: clean (alpha.1-alpha.3 PASS baseline, five templates parsed)
+```
+
+Il confirme notamment les trois skeletons attendus, les histories `alpha.1` à `alpha.3` en `PASS`, les owners `500-LANGUAGES.md` et `510-RUST_CARGO.md`, les cinq templates Rust/Cargo référencés et leur parsing TOML.
+
+La toolchain opérateur observée est disponible :
+
+```text
+cargo 1.94.1 (29ea6fb6a 2026-03-24)
+rustc 1.94.1 (e408947bf 2026-03-25)
+rustfmt 1.8.0-stable (e408947bfd 2026-03-25)
+clippy 0.1.94 (e408947bfd 2026-03-25)
+```
+
+Après l'assertion défectueuse, les commandes Cargo ont été exécutées sur le workspace temporaire et ont réussi :
+
+```text
+cargo metadata --format-version 1 --no-deps
+cargo fmt --all -- --check
+cargo check --workspace
+cargo clippy --workspace --all-targets --all-features -- -D warnings
+```
+
+`cargo check` et `cargo clippy` ont tous deux terminé avec succès pour `smoke-core-lib v1.2.3`.
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le scope Git observé avant le présent history est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.0.4/alpha.4.md
+M  docs/000-README.md
+M  docs/skeletons/000-README.md
+A  docs/skeletons/002-RUST_CARGO_WORKSPACE.md
+```
+
+## Défaut exact
+
+La gate copie `templates/rust-cargo/.cargo/config.toml`, puis remplace le chemin :
+
+```text
+../builds/project-name/target
+```
+
+par :
+
+```text
+target-smoke
+```
+
+Les deux valeurs `target-dir` et `build-dir` sont donc adaptées correctement. Cependant, le template contient aussi le commentaire :
+
+```text
+# Replace project-name with a unique name before using this configuration.
+```
+
+Le script d'instanciation ne remplace pas ce commentaire, puis vérifie volontairement qu'aucun placeholder `project-name` ou `project-core-lib` ne subsiste dans les fichiers copiés. L'assertion échoue donc sur :
+
+```text
+/tmp/.../.cargo/config.toml
+```
+
+avec :
+
+```text
+AssertionError
+```
+
+Le workspace généré reste compilable, comme le montrent les commandes Cargo réussies ensuite, mais une commande obligatoire de la gate a échoué. La tranche ne peut donc pas être déclarée `PASS`.
+
+## Décision
+
+Aucun REPLAN n'est requis.
+
+Le défaut appartient uniquement au smoke d'instanciation défini dans la gate de `alpha.4`. Les règles, le skeleton `002` et les cinq templates livrés restent inchangés.
+
+La correction reste strictement locale :
+
+```text
+0.0.4-alpha.4.fix.1
+```
+
+Le delta `alpha.4` livré reste un snapshot historique et n'est pas réécrit. Le fix corrige la procédure de smoke en adaptant aussi le commentaire de `.cargo/config.toml`, puis rejoue les contrôles nécessaires.
+
+## Résultat
+
+`0.0.4-alpha.4` est enregistré `FAIL`.
+
+La seule transition autorisée est :
+
+```text
+0.0.4-alpha.4.fix.1
+```

history/0.0.4/beta.1.fix.1.md

@@ -0,0 +1,85 @@
+<!-- file: history/0.0.4/beta.1.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-beta.1.fix.1 — correction de la gate de réconciliation
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.0.4-beta.1.fix.1` exécutée le `2026-09-24` confirme que l'échec de `beta.1` provenait uniquement de la syntaxe de sa gate et que la réconciliation interne prévue est propre après correction.
+
+Le history `beta.1` reste enregistré `FAIL` et n'est pas réécrit rétroactivement.
+
+## Baseline et version
+
+La tranche précédente `0.0.4-beta.1` a été committée et poussée sous le commit observé :
+
+```text
+fdaaa35
+```
+
+Ce commit contient `history/0.0.4/beta.1.md` avec statut `FAIL`. Le history de `alpha.4.fix.1` reste présent avec statut `PASS`.
+
+La version contrôlée après application du fix est :
+
+```text
+0.0.4-beta.1.fix.1
+```
+
+Le delta `deltas/0.0.4/beta.1.fix.1.md` est présent et `history/0.0.4/beta.1.fix.1.md` était absent pendant la gate.
+
+## Validation opérateur observée
+
+La suite Python a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.238s
+
+OK
+```
+
+Les trois audits Markdown ont réussi :
+
+```text
+Markdown header audit: clean (117 file(s))
+Markdown table audit: clean (3 table(s), 117 file(s))
+Markdown link audit: clean (113 local link(s), 117 file(s))
+```
+
+L'audit Python corrigé de réconciliation s'est exécuté jusqu'à son terme et a affiché :
+
+```text
+Skeleton beta reconciliation fix audit: clean (beta.1 FAIL recorded, 3 skeleton docs, 5 TOML parsed)
+```
+
+Il confirme notamment :
+
+- la chaîne historique `alpha.1 = PASS`, `alpha.2 = PASS`, `alpha.3 = PASS`, `alpha.4 = FAIL`, `alpha.4.fix.1 = PASS`, `beta.1 = FAIL` ;
+- la présence exclusive des trois documents de la collection skeletons : index, fondation gouvernée et spécialisation Rust/Cargo ;
+- les owners généraux `200/210/300/400` de la fondation et `500/510` de la spécialisation Rust/Cargo ;
+- le caractère adaptable et non universel des valeurs `0.1.0`, `2024`, `project-name` et `project-core-lib` ;
+- les limites documentées des audits Markdown et Rust ;
+- le maintien du différé Java/Maven/Gradle, Android, Web, JNI et Tauri ;
+- le parsing réussi des cinq fichiers TOML Rust/Cargo.
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le scope Git observé avant ce history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/beta.1.fix.1.md
+```
+
+La transcription du terminal intercale des fragments de heredoc avec les sorties des tests et audits ; les résultats finaux et le statut Git restent néanmoins explicites et aucun échec n'est présent dans cette gate corrigée.
+
+## Revue de cohérence
+
+Aucune correction de contenu PGR n'est requise par ce fix. Les règles, skeletons, templates, scripts, tests et documents vivants restent inchangés par rapport à `beta.1`.
+
+La réconciliation confirme que `220-SKELETONS.md` possède le contrat transversal tandis que les skeletons `001` et `002` composent les owners existants sans les redéfinir. Les domaines différés restent absents sans placeholder anticipé.
+
+## Transition
+
+`0.0.4-beta.1.fix.1` est enregistré `PASS`.
+
+Appliquer ce history, committer et pousser la tranche avant d'appliquer `0.0.4-rc.1`. Le commit futur de ce fix n'est pas attesté par la transcription fournie.

history/0.0.4/beta.1.md

@@ -0,0 +1,97 @@
+<!-- file: history/0.0.4/beta.1.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-beta.1 — réconciliation interne des skeletons
+
+## Statut
+
+FAIL
+
+La tranche `0.0.4-beta.1` n'est pas enregistrée `PASS` telle quelle.
+
+Les tests Python, les trois audits Markdown, les contrôles de présence et le scope Git ont réussi, mais le script Python de réconciliation embarqué dans la gate contient une erreur de syntaxe. Une commande obligatoire ayant échoué, la tranche doit rester `FAIL` même si le défaut appartient uniquement à la gate et non au contenu réconcilié.
+
+## Baseline et version
+
+La tranche précédente `0.0.4-alpha.4.fix.1` a été committée et poussée sous le commit observé :
+
+```text
+ea80396
+```
+
+Ce commit contient `history/0.0.4/alpha.4.fix.1.md` avec statut `PASS` et conserve `history/0.0.4/alpha.4.md` avec statut `FAIL`.
+
+La version contrôlée après application de `beta.1` est :
+
+```text
+0.0.4-beta.1
+```
+
+`deltas/0.0.4/beta.1.md` est présent et `history/0.0.4/beta.1.md` était absent pendant la gate.
+
+## Contrôles réussis observés
+
+Les contrôles initiaux ont confirmé la présence des deux skeletons concrets et l'absence des skeletons Java/Android différés. Les histories `alpha.4` et `alpha.4.fix.1` ont respectivement été observés en `FAIL` et `PASS`.
+
+La suite Python globale a exécuté `15` tests, tous réussis :
+
+```text
+Ran 15 tests in 0.223s
+
+OK
+```
+
+Les trois audits Markdown ont réussi :
+
+```text
+Markdown header audit: clean (115 file(s))
+Markdown table audit: clean (3 table(s), 115 file(s))
+Markdown link audit: clean (113 local link(s), 115 file(s))
+```
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le scope Git observé avant le présent history est exactement :
+
+```text
+M  VERSION
+A  deltas/0.0.4/beta.1.md
+```
+
+La transcription du terminal contient des fragments de heredoc intercalés avec les sorties des tests ; les résultats finaux ci-dessus restent identifiables.
+
+## Défaut exact
+
+Le script Python de réconciliation contient l'assertion suivante :
+
+```python
+assert 'Les audits ne modifient ni les fichiers inspectés ni l'arborescence de build.' in rust_audits
+```
+
+La chaîne Python est délimitée par des apostrophes simples et contient elle-même l'apostrophe de `l'arborescence`. Le parseur s'arrête donc avant l'exécution des assertions avec :
+
+```text
+SyntaxError: unterminated string literal (detected at line 67)
+```
+
+Le défaut est purement syntaxique dans la gate `beta.1`. Aucun résultat de cette commande de réconciliation ne peut être considéré comme acquis, même si les contrôles précédents ont réussi.
+
+## Décision
+
+Aucun REPLAN n'est requis.
+
+Le delta `beta.1` et le présent history restent des snapshots historiques et ne doivent pas être réécrits. La correction doit être limitée à une tranche :
+
+```text
+0.0.4-beta.1.fix.1
+```
+
+Ce fix ne modifie aucun document vivant, skeleton, template, script ou test. Il rejoue la réconciliation avec une chaîne Python correctement délimitée, ainsi que les contrôles nécessaires pour confirmer que le contenu de `beta.1` était cohérent.
+
+## Résultat
+
+`0.0.4-beta.1` est enregistré `FAIL`.
+
+La seule transition autorisée est :
+
+```text
+0.0.4-beta.1.fix.1
+```

history/0.0.4/rc.1.md

@@ -0,0 +1,92 @@
+<!-- file: history/0.0.4/rc.1.md -->
+<!-- version: 1 -->
+
+# History 0.0.4-rc.1 — gate de release candidate
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.0.4-rc.1` exécutée le `2026-09-24` valide le gel fonctionnel de la release candidate, sa présentation candidate, le prompt de reprise `005` et le smoke d'instanciation Rust/Cargo. Cette preuve porte sur la RC avant son commit ; elle ne constitue ni la promotion stable, ni le tag `v0.0.4`, ni une vérification post-tag.
+
+## Baseline et scope observés
+
+La baseline opérateur est le commit `3f8fa6b` de `0.0.4-beta.1.fix.1`, poussé sur `master` avant application du delta RC. L'opérateur a confirmé `VERSION = 0.0.4-rc.1`, la présence dans `HEAD` de `history/0.0.4/beta.1.fix.1.md`, la présence du delta `rc.1` et du prompt `005`, ainsi que l'absence du présent history avant sa livraison.
+
+Les révisions et marqueurs attendus ont été retrouvés :
+
+```text
+CHANGELOG.md                                      version 6
+CHANGELOG                                         0.0.4 (candidate)
+docs/plans/004-V0_0_4_SKELETONS_PLAN.md          version 2
+beta.1.fix.1                                      PASS consigné dans le plan
+prompts/005-V0_0_5_START_PROMPT.md                baseline pgr-v0.0.4.zip
+prompts/005-V0_0_5_START_PROMPT.md                khadhroony-solana-project
+prompts/005-V0_0_5_START_PROMPT.md                sasedev-games
+```
+
+Le prompt `005` reste conditionnel : il demande explicitement les baselines réelles de KSP et `sasedev-games`, interdit d'en déduire version, commit ou contenu, et ne présente le rapport `pgr-0.0.4-publish.001-report.md` comme disponible que s'il a réellement été produit et validé.
+
+## Tests et audits documentaires
+
+Les `15` tests Python ciblés ont tous réussi :
+
+```text
+Ran 15 tests in 0.212s
+OK
+```
+
+Les trois audits Markdown ont affiché :
+
+```text
+Markdown header audit: clean (120 file(s))
+Markdown table audit: clean (3 table(s), 120 file(s))
+Markdown link audit: clean (116 local link(s), 120 file(s))
+```
+
+L'audit d'intégration RC a affiché :
+
+```text
+RC integration audit: clean (7 prior histories, 3 skeleton docs, 5 TOML parsed, prompt 005 ready)
+```
+
+Il confirme notamment les statuts historiques précédents (`alpha.4 = FAIL`, `alpha.4.fix.1 = PASS`, `beta.1 = FAIL`, `beta.1.fix.1 = PASS`), les trois documents de la collection skeletons, les owners attendus, les cinq TOML Rust/Cargo lisibles et la disponibilité du prompt `005`.
+
+## Smoke Rust/Cargo observé
+
+La toolchain observée est :
+
+```text
+cargo 1.94.1 (29ea6fb6a 2026-03-24)
+rustc 1.94.1 (e408947bf 2026-03-25)
+rustfmt 1.8.0-stable (e408947bfd 2026-03-25)
+clippy 0.1.94 (e408947bfd 2026-03-25)
+```
+
+L'adaptation temporaire des cinq templates a terminé par :
+
+```text
+RC temporary Rust/Cargo template adaptation: clean
+```
+
+Le workspace temporaire `smoke-core-lib v1.2.3` a ensuite passé `cargo metadata`, `cargo fmt --all -- --check`, `cargo check --workspace` et `cargo clippy --workspace --all-targets --all-features -- -D warnings`. Les sorties Cargo de `check` et `clippy` se terminent toutes deux par `Finished dev profile` sans diagnostic bloquant.
+
+Le répertoire temporaire a été supprimé et le trap désarmé après le smoke ; aucun artefact de cette instanciation n'entre dans PGR.
+
+## Scope Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Après ajout des fichiers RC, le statut indexé transmis est exactement :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.0.4/rc.1.md
+M  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+A  prompts/005-V0_0_5_START_PROMPT.md
+```
+
+La revue du contenu confirme que le changelog décrit la release plutôt que ses tranches internes, que les deux `FAIL` historiques restent visibles avec leurs fixes `PASS`, que le prompt `005` ne présume aucune baseline KSP/Games non fournie et qu'aucun nouveau skeleton, profil, template, audit ou domaine technologique n'a été introduit en RC.
+
+## Transition
+
+Appliquer ce history puis committer/pousser `0.0.4-rc.1`. Ensuite seulement appliquer le delta stable `rel.001`. La promotion stable reste pré-tag : le tag `v0.0.4`, son archive source Gitea et le rapport post-tag `publish.001` ne pourront être attestés qu'après un `rel.001` PASS, son history, le commit stable et la publication réelle du tag.

history/0.0.4/rel.001.md

@@ -0,0 +1,86 @@
+<!-- file: history/0.0.4/rel.001.md -->
+<!-- version: 1 -->
+
+# History 0.0.4 rel.001 — clôture stable pré-tag
+
+## Statut
+
+PASS
+
+La gate stable pré-tag `rel.001` exécutée par l'opérateur le `2026-09-24` valide la promotion documentaire de `0.0.4`. Cette preuve porte sur l'état du dépôt avant le commit stable et avant le tag `v0.0.4` ; elle ne valide pas encore l'archive source publiée ensuite par Gitea.
+
+## Baseline et version
+
+La baseline opérateur est le commit `c6af96b` de `0.0.4-rc.1`, poussé sur `master` avant application du delta stable. L'opérateur a confirmé `VERSION = 0.0.4`, la présence dans `HEAD` de `history/0.0.4/rc.1.md`, la présence du delta `rel.001` et du prompt `005`, ainsi que l'absence du présent history avant sa livraison.
+
+Les révisions et marqueurs de clôture attendus ont été retrouvés :
+
+```text
+README.md                                      version 11
+ROADMAP.md                                     version 5
+CHANGELOG.md                                   version 7
+docs/000-README.md                             version 9
+docs/plans/004-V0_0_4_SKELETONS_PLAN.md       version 3
+ROADMAP                                        0.0.4 terminé
+CHANGELOG                                      entrée stable ## 0.0.4
+plan 004                                       plan historique, rc.1 PASS
+```
+
+La présentation du dépôt décrit désormais `0.0.4` comme la release qui définit le contrat transversal des skeleton specifications, ajoute la fondation gouvernée `001` et la spécialisation Rust/Cargo `002`, tout en maintenant le différé des autres spécialisations technologiques insuffisamment matérialisées.
+
+## Chaîne historique
+
+L'audit de la chaîne `0.0.4` a affiché :
+
+```text
+Stable history audit: clean (8 prior histories with expected statuses, rel.001 pending)
+```
+
+Les statuts antérieurs observés et conservés sont :
+
+```text
+alpha.1          PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          FAIL
+alpha.4.fix.1    PASS
+beta.1           FAIL
+beta.1.fix.1     PASS
+rc.1             PASS
+```
+
+Les deux échecs historiques restent donc conservés avec leurs correctifs `PASS`; `rel.001` était le seul delta de `0.0.4` encore sans history au moment de la gate.
+
+## Audits documentaires
+
+Les trois audits Markdown ont affiché :
+
+```text
+Markdown header audit: clean (122 file(s))
+Markdown table audit: clean (3 table(s), 122 file(s))
+Markdown link audit: clean (116 local link(s), 122 file(s))
+```
+
+Les `15` tests Python, les cinq TOML Rust/Cargo et le smoke d'instanciation complet avaient été validés dans `rc.1`. Ils n'ont pas été rejoués pendant cette gate stable, conformément au delta `rel.001`, car aucun code, script, test, template ou skeleton technique n'est modifié par la promotion documentaire.
+
+## Scope Git observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Après ajout des fichiers du delta, le statut indexé transmis est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.0.4/rel.001.md
+M  docs/000-README.md
+M  docs/plans/004-V0_0_4_SKELETONS_PLAN.md
+```
+
+La revue opérateur confirme que le scope fonctionnel gelé en RC n'a pas changé, que README/roadmap/changelog/index/plan décrivent la même stable, que le prompt `005` reste conditionnel à une publication réelle et à des baselines KSP/Games explicitement fournies, et qu'aucune preuve post-tag n'est anticipée.
+
+## Transition
+
+Appliquer ce history puis committer et pousser la stable `0.0.4`. Ensuite seulement créer et publier le tag canonique `v0.0.4`, télécharger l'archive source associée depuis Gitea et exécuter une vérification post-tag indépendante.
+
+Le commit stable, le tag, l'identité de l'archive publiée et le résultat du contrôle post-tag ne sont pas attestés par la transcription reçue. Le rapport `pgr-0.0.4-publish.001-report.md` ne pourra être produit qu'après ces opérations réelles ; le démarrage de `0.0.5` reste bloqué jusqu'à cette preuve post-tag `PASS` et à la fourniture des baselines autoritaires demandées par `prompts/005-V0_0_5_START_PROMPT.md`.

prompts/005-V0_0_5_START_PROMPT.md

@@ -0,0 +1,66 @@
+<!-- file: prompts/005-V0_0_5_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.0.5 — réconciliation réelle avec KSP et sasedev-games
+
+## Baseline PGR et cible
+
+Dépôt canonique PGR : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline PGR attendue au démarrage effectif de `0.0.5` est l'archive source téléchargée depuis le tag Gitea `v0.0.4`, dont le nom attendu est `pgr-v0.0.4.zip`. Une archive source peut légitimement ne pas contenir `.git` ; vérifier son contenu et ses artefacts de gouvernance sans lui attribuer une preuve Git qu'elle ne peut contenir.
+
+Version cible : `0.0.5`. Première tranche attendue : `0.0.5-alpha.1`.
+
+Si un rapport séparé `pgr-0.0.4-publish.001-report.md` a effectivement été produit et conclut `PASS`, le fournir avec l'archive. S'il est absent ou non validé, le signaler explicitement ; ne jamais présumer la publication ou un résultat PASS. Ce rapport ne fait pas partie du tag et ne remplace pas l'audit de la nouvelle session.
+
+## Sources de réconciliation externes
+
+`0.0.5` doit confronter PGR à des états réels de `khadhroony-solana-project` et `sasedev-games`. Les baselines exactes de ces deux projets doivent donc être fournies explicitement à la session sous forme d'archives, tags ou autres snapshots autoritaires clairement identifiés.
+
+Ne pas déduire leur version, leur commit ou leur contenu d'une conversation précédente, d'un workspace local non fourni ou d'un souvenir de projet. Si l'une des deux sources manque, l'indiquer et borner l'audit à ce qui est effectivement disponible au lieu de fabriquer une comparaison complète.
+
+Ces projets sont des corpus de réconciliation. Leurs conventions locales ne deviennent pas automatiquement des règles PGR, et PGR ne doit pas leur imposer rétroactivement une règle sans avoir distingué le besoin commun du besoin spécifique au projet.
+
+## Reprise manuelle après publication
+
+Après vérification réelle de l'archive du tag PGR et du rapport post-tag PASS, remettre spontanément à l'opérateur un message de reprise adapté selon [`docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md).
+
+Si les noms PGR attendus ci-dessus sont confirmés et le rapport est PASS, la base de la phrase est :
+
+```text
+Partir de l'archive pgr-v0.0.4.zip téléchargée depuis le tag Gitea v0.0.4 et du rapport post-tag pgr-0.0.4-publish.001-report.md. Lire et exécuter prompts/005-V0_0_5_START_PROMPT.md. Vérifier l'archive PGR et les baselines autoritaires fournies de khadhroony-solana-project et sasedev-games avant de préparer 0.0.5-alpha.1.
+```
+
+Si le rapport manque ou n'est pas PASS, retirer sa mention et transmettre son état réel séparément. Adapter également les références KSP/Games aux fichiers ou tags réellement fournis. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag de `0.0.4`, jamais comme attestation anticipée au stade RC.
+
+## Mission
+
+Réaliser la première réconciliation explicite de PGR avec deux projets réels qui ont servi de corpus de conception : `khadhroony-solana-project` et `sasedev-games`.
+
+`alpha.1` MUST commencer par auditer indépendamment la stable `v0.0.4`, ses règles, profils, templates, skeleton specifications, audits et chaîne delta/history. Elle doit ensuite inventorier les règles, conventions, structures et audits réellement présents dans les deux baselines externes fournies, puis classer chaque écart avant toute modification importante.
+
+La réconciliation doit distinguer au minimum :
+
+- ce qui est déjà correctement possédé par PGR et seulement appliqué localement ;
+- ce qui révèle un besoin commun manquant ou insuffisamment spécifié dans PGR ;
+- ce qui doit rester spécifique à KSP ou à Games ;
+- ce qui est devenu obsolète, redondant ou contradictoire dans un projet par rapport au modèle PGR actuel ;
+- ce qui nécessite un nouveau profil, template, skeleton ou audit uniquement si un besoin réel et réutilisable le justifie.
+
+Fixer ensuite un plan `0.0.5` proportionné. Ne pas transformer la phase d'inventaire en migration massive des projets et ne pas supposer qu'une divergence doit forcément être résolue du côté PGR.
+
+## Principes de réconciliation
+
+- Comparer des responsabilités et propriétés concrètes, pas seulement des noms de fichiers ou des structures visuellement similaires.
+- Conserver un propriétaire normatif unique et éviter de recopier dans PGR une règle déjà possédée ailleurs sous une forme plus générale.
+- Ne généraliser une convention locale KSP/Games que lorsqu'au moins son besoin et son contrat sont réellement réutilisables.
+- Préserver les exceptions locales motivées et les contraintes propres à une plateforme, un protocole, une application ou une phase de développement.
+- Réutiliser les audits PGR existants lorsqu'ils contrôlent déjà la propriété recherchée ; ne pas recréer des scripts composites uniquement parce qu'ils existent dans un projet source.
+- Vérifier les skeletons `001` et `002` contre des usages réels sans considérer leur adoption intégrale comme obligatoire.
+- Documenter explicitement les éléments différés si les preuves disponibles ne suffisent pas à créer un owner ou un artefact PGR durable.
+
+## Workflow
+
+Suivre `RULES.md`, [`docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md) et [`docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md). La séquence reste delta → gate opérateur → history constaté → application du history → commit → delta suivant.
+
+Les baselines externes servent à l'analyse et à la preuve. Une modification effective de KSP ou de `sasedev-games`, si elle devient nécessaire, doit être explicitement planifiée et validée dans le scope approprié ; elle ne doit pas être cachée dans un delta PGR.