0.0.4-alpha.2

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 7 -->
+<!-- version: 8 -->
 
 # Project Governance Rules
 
@@ -28,6 +28,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `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 actif 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/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
 
 ## Langue et nomenclature

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.4-alpha.1
+0.0.4-alpha.2

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.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # 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.
 
@@ -22,6 +23,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 
 - [`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) — cadrage actif des premières skeleton specifications et de leur composition ;
+- [`skeletons/000-README.md`](skeletons/000-README.md) — contrat de collection des skeleton specifications ;
 - [`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/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,24 @@
+<!-- file: docs/skeletons/000-README.md -->
+<!-- version: 1 -->
+
+# 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.
+
+## État courant
+
+`0.0.4-alpha.2` active le contrat et l'index de cette collection sans créer encore de skeleton concret.
+
+Le plan [`../plans/004-V0_0_4_SKELETONS_PLAN.md`](../plans/004-V0_0_4_SKELETONS_PLAN.md) prévoit ensuite une fondation de projet gouverné, puis une specialization Rust/Cargo fondée sur les profils et templates déjà disponibles. Les familles Java/Android, Web, JNI, Tauri et autres domaines sans pièces suffisantes restent différées.
+
+Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.

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.