This commit is contained in:
2026-09-23 15:57:03 +02:00
parent 3ba513da16
commit 1b37d2752a
6 changed files with 286 additions and 7 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: README.md --> <!-- file: README.md -->
<!-- version: 3 --> <!-- version: 4 -->
# Project Governance Rules # 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`. 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 ; les releases suivantes de la série `0.0.x` introduisent progressivement profils technologiques, templates techniques et spécifications de skeletons. 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 le premier modèle de profils réutilisables, les profils Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown génériques monotâches. Les releases suivantes de la série `0.0.x` poursuivent avec templates techniques et spécifications de skeletons.
## Entrées principales ## Entrées principales
@@ -25,6 +25,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
- [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md) — profil applicable au dépôt PGR ; - [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md) — profil applicable au dépôt PGR ;
- [`docs/architecture/002-GOVERNANCE_ARCHITECTURE.md`](docs/architecture/002-GOVERNANCE_ARCHITECTURE.md) — architecture du référentiel ; - [`docs/architecture/002-GOVERNANCE_ARCHITECTURE.md`](docs/architecture/002-GOVERNANCE_ARCHITECTURE.md) — architecture du référentiel ;
- [`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/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/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation. - [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
## Langue et nomenclature ## Langue et nomenclature

View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md --> <!-- file: ROADMAP.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Roadmap Project Governance Rules # Roadmap Project Governance Rules
@@ -10,7 +10,7 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
## Fondation `0.0.x` ## Fondation `0.0.x`
- `(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.1` — fondation normative et documentaire : gouvernance, lifecycle des releases, rôles documentaires, workflow delta/history/handoff et validation proportionnée ;
- `( ) 0.0.2` — profils de règles par langage, plateforme, framework et type de projet ; - `(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 ;
- `( ) 0.0.3` — templates techniques initiaux et premiers patterns d'audit réutilisables issus de besoins réels ; - `( ) 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 ; - `( ) 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`. - `( ) 0.0.5` — réconciliation réelle de PGR avec `khadhroony-solana-project` et `sasedev-games`.

View File

@@ -1 +1 @@
0.0.2-rc.1.fix.1 0.0.2

154
deltas/0.0.2/rel.001.md Normal file
View File

@@ -0,0 +1,154 @@
<!-- file: deltas/0.0.2/rel.001.md -->
<!-- version: 1 -->
# Delta 0.0.2 rel.001 — promotion stable
## Baseline
Version attendue avant application :
```text
0.0.2-rc.1.fix.1
```
Le history `history/0.0.2/rc.1.fix.1.md` MUST avoir été appliqué et committé avant ce delta.
Version après application :
```text
0.0.2
```
`rel.001` est l'identifiant opérationnel de cette clôture stable ; il ne fait pas partie de la version SemVer produit.
## Objet
Promouvoir mécaniquement la release candidate validée vers la stable `0.0.2`, finaliser les métadonnées vivantes de la release et préparer le commit/tag stable.
Cette tranche n'introduit aucune nouvelle règle normative, aucun nouveau profil, aucun nouvel audit et aucun nouveau scope fonctionnel.
## Scope
REPLACE :
```text
VERSION
README.md
ROADMAP.md
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
```
ADD :
```text
deltas/0.0.2/rel.001.md
```
DELETE : aucun.
## Changements
- `VERSION` devient `0.0.2` ;
- `README.md` présente `0.0.2` comme la première release matérialisant des profils technologiques réutilisables et référence son plan historique ;
- `ROADMAP.md` marque `0.0.2` terminé ;
- le plan `0.0.2` est clôturé après `rc.1.fix.1` et rappelle la séparation entre `rel.001` pré-tag et `publish.001` post-tag ;
- `CHANGELOG.md` n'est pas modifié : l'entrée stable `0.0.2` préparée en RC est déjà finalisée ;
- `prompts/003-V0_0_3_START_PROMPT.md` n'est pas modifié : il cible déjà `v0.0.2` et demande explicitement le rapport post-tag lorsqu'il existe.
## Validation opérateur
```bash
test "$(cat VERSION)" = "0.0.2"
grep -F 'La release `0.0.2` ajoute le premier modèle de profils réutilisables' README.md
grep -F 'plan historique des premiers profils `0.0.2`' README.md
grep -F -- '- `(x) 0.0.2`' ROADMAP.md
grep -F 'Plan clôturé par la promotion stable `0.0.2` après validation de `0.0.2-rc.1.fix.1`.' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
grep -F 'Le contrôle post-tag `publish.001` reste une preuve séparée' docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
grep -Fx '## 0.0.2' CHANGELOG.md
test -f prompts/003-V0_0_3_START_PROMPT.md
grep -F 'v0.0.2' prompts/003-V0_0_3_START_PROMPT.md
grep -F 'pgr-0.0.2-publish.001-report.md' prompts/003-V0_0_3_START_PROMPT.md
for delta in deltas/0.0.2/*.md; do
name="${delta##*/}"
if [ "$name" = 'rel.001.md' ]; then
continue
fi
test -f "history/0.0.2/$name" || {
echo "Missing history for ${delta}" >&2
exit 1
}
done
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
roots = [Path(name) for name in ('README.md', 'RULES.md', 'ROADMAP.md', 'CHANGELOG.md')]
for directory in ('docs', 'deltas', 'history', 'prompts'):
roots.extend(Path(directory).rglob('*.md'))
paths = sorted(set(roots))
errors = []
for path in paths:
lines = path.read_text(encoding='utf-8').splitlines()
expected = f'<!-- file: {path.as_posix()} -->'
if len(lines) < 2 or lines[0] != expected:
errors.append(f'{path}: invalid file header')
elif re.fullmatch(r'<!-- version: [1-9][0-9]* -->', lines[1]) is None:
errors.append(f'{path}: invalid version header')
if errors:
for error in errors:
print(error)
raise SystemExit(1)
print(f'Markdown header audit: clean ({len(paths)} file(s))')
PY
git diff --check
git add VERSION README.md ROADMAP.md \
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md \
deltas/0.0.2/rel.001.md
git diff --cached --check
git status --short
```
La sortie attendue avant ajout du history est exactement :
```text
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.2/rel.001.md
M docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
```
## Revue opérateur complémentaire
- confirmer que la promotion stable ne contient aucun changement fonctionnel ou normatif nouveau ;
- confirmer que `0.0.2` clôt uniquement les profils `510`, `520` et `610` retenus par le plan ;
- confirmer que les profils différés restent différés ;
- confirmer que le prompt `0.0.3` demande explicitement l'archive taggée et le rapport `publish.001` lorsqu'il existe ;
- confirmer que `CHANGELOG.md` décrit la stable utilement sans recopier les détails de prerelease.
## Transition
### PASS
Créer et appliquer séparément `history/0.0.2/rel.001.md`, committer la stable `0.0.2`, créer le tag `v0.0.2`, pousser commit et tag, puis télécharger l'archive source produite depuis ce tag et exécuter la vérification post-tag `publish.001`.
### FAIL
Ne pas créer le tag. Corriger la promotion stable dans une nouvelle tranche de clôture explicite avant toute publication.

View File

@@ -1,11 +1,11 @@
<!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md --> <!-- file: docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md -->
<!-- version: 5 --> <!-- version: 6 -->
# Plan 0.0.2 — premiers profils de règles technologiques # Plan 0.0.2 — premiers profils de règles technologiques
## Statut ## Statut
Plan actif entré en release candidate pendant `0.0.2-rc.1`, après cadrage en `alpha.1`, matérialisation des profils retenus puis réconciliation beta. Plan clôturé par la promotion stable `0.0.2` après validation de `0.0.2-rc.1.fix.1`.
La baseline `v0.0.1` est cohérente pour démarrer `0.0.2`. L'absence de `.git` dans cette archive est normale et n'est pas une anomalie de baseline. La baseline `v0.0.1` est cohérente pour démarrer `0.0.2`. L'absence de `.git` dans cette archive est normale et n'est pas une anomalie de baseline.
@@ -187,6 +187,14 @@ Le prompt `0.0.3` doit aussi fournir explicitement le texte manuel de nouvelle s
Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer `rel.001`, commit/tag `v0.0.2`, puis vérifier séparément l'archive publiée issue du tag. Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer `rel.001`, commit/tag `v0.0.2`, puis vérifier séparément l'archive publiée issue du tag.
## Clôture
La release candidate `rc.1` a été enregistrée `FAIL` à cause d'un audit Python inline invalide dans sa gate. `rc.1.fix.1` a corrigé exclusivement cette commande et a ensuite été validée `PASS`, sans changement du scope fonctionnel ou normatif.
La promotion stable `rel.001` clôt le plan en mettant à jour uniquement les métadonnées vivantes de release et en préparant le tag `v0.0.2`.
Le contrôle post-tag `publish.001` reste une preuve séparée : il doit vérifier l'archive réellement produite depuis le tag et fournir `pgr-0.0.2-publish.001-report.md` à la future session `0.0.3` lorsqu'il est `PASS`.
## Dimensionnement et points de replan ## Dimensionnement et points de replan
Le premier forecast `alpha.2` à `alpha.8` a été jugé trop large pendant la revue opérateur de `alpha.1`. Le présent plan réduit donc la release avant tout développement technologique lourd. Le premier forecast `alpha.2` à `alpha.8` a été jugé trop large pendant la revue opérateur de `alpha.1`. Le présent plan réduit donc la release avant tout développement technologique lourd.

116
history/0.0.2/rel.001.md Normal file
View File

@@ -0,0 +1,116 @@
<!-- file: history/0.0.2/rel.001.md -->
<!-- version: 1 -->
# History 0.0.2-rel.001 — promotion stable pré-tag
## Statut
PASS
La tranche `0.0.2-rel.001` a été validée par l'opérateur.
La promotion stable vers `0.0.2` est cohérente avant création du tag. Le contrôle post-tag `publish.001` reste une étape séparée et doit porter sur l'archive réellement produite depuis le tag `v0.0.2`.
## Baseline
La tranche précédente `0.0.2-rc.1.fix.1` a été validée `PASS`, puis committée et poussée sous le commit observé :
```text
3ba513d
```
Version contrôlée après application de `rel.001` :
```text
0.0.2
```
## Validation opérateur observée
La version stable a été confirmée :
```bash
test "$(cat VERSION)" = "0.0.2"
```
Les marqueurs de clôture stable ont été retrouvés :
```text
README.md
→ La release `0.0.2` ajoute le premier modèle de profils réutilisables
README.md
→ plan historique des premiers profils `0.0.2`
ROADMAP.md
→ `(x) 0.0.2`
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
→ Plan clôturé par la promotion stable `0.0.2` après validation de `0.0.2-rc.1.fix.1`.
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
→ Le contrôle post-tag `publish.001` reste une preuve séparée
```
Le `CHANGELOG.md` contient exactement l'entrée :
```text
## 0.0.2
```
Le prompt de reprise `prompts/003-V0_0_3_START_PROMPT.md` existe et référence correctement :
```text
v0.0.2
pgr-v0.0.2.zip
pgr-0.0.2-publish.001-report.md
```
## Pairing deltas / histories
La boucle de contrôle a vérifié que chaque delta `deltas/0.0.2/*.md` antérieur à `rel.001.md` possède son history correspondant.
Aucun history manquant n'a été signalé.
## Audits documentaires
Résultats observés :
```text
Markdown table audit: clean (2 table(s), 72 file(s))
Markdown link audit: clean (50 local link(s), 72 file(s))
Markdown header audit: clean (72 file(s))
```
## Contrôles Git
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope Git observé avant ajout du présent history est exactement :
```text
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.2/rel.001.md
M docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
```
## Résultat
`0.0.2-rel.001` est validée `PASS`.
L'état est prêt pour :
```text
1. application du présent history ;
2. commit stable `0.0.2` ;
3. push du commit stable ;
4. création du tag `v0.0.2` sur ce commit ;
5. push du tag ;
6. téléchargement de l'archive ZIP produite depuis ce tag ;
7. contrôle post-tag `publish.001` de cette archive réelle ;
8. production de `pgr-0.0.2-publish.001-report.md`.
```
Le tag ne doit pas être considéré publié correctement tant que `publish.001` n'a pas contrôlé l'archive réellement servie par la forge.