Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.4-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-24 14:39:29 +02:00
parent 7408616909
commit 5471ea6283
7 changed files with 427 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# 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 série `0.0.x` se poursuit avec les spécifications de skeletons de `0.0.4`. Le contrat transversal et la première fondation de projet gouverné sont désormais matérialisés ; les spécialisations technologiques restent composables et séparées.
## Entrées principales
@@ -29,6 +29,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
- [`docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — plan historique des templates et audits `0.0.3` ;
- [`docs/plans/004-V0_0_4_SKELETONS_PLAN.md`](docs/plans/004-V0_0_4_SKELETONS_PLAN.md) — plan 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/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;
- [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
## Langue et nomenclature

2
VERSION
View File

@@ -1 +1 @@
0.0.4-alpha.2
0.0.4-alpha.3

167
deltas/0.0.4/alpha.3.md Normal file
View File

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

3
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Documentation PGR
@@ -24,6 +24,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 ;
- [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation de gouvernance locale composable et sans spécialisation technologique ;
- [`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.

8
docs/skeletons/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/skeletons/000-README.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Index des skeleton specifications PGR
@@ -15,10 +15,10 @@ Les fichiers techniques copiables ne vivent pas ici : ils restent sous `template
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
## Specifications actives
`0.0.4-alpha.2` active le contrat et l'index de cette collection sans créer encore de skeleton concret.
- [`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.
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.
Le plan [`../plans/004-V0_0_4_SKELETONS_PLAN.md`](../plans/004-V0_0_4_SKELETONS_PLAN.md) prévoit ensuite une specialization Rust/Cargo fondée sur cette fondation, les profils `500 + 510` et les 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.

154
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md Normal file
View File

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

96
history/0.0.4/alpha.3.md Normal file
View File

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