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

0.0.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-24 13:28:35 +02:00
parent ec3a101d9b
commit 1e10feba95
8 changed files with 180 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
CHANGELOG.md
View File

@@ -1,5 +1,5 @@
<!-- file: CHANGELOG.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Changelog Project Governance Rules
@@ -7,7 +7,7 @@ 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.3 (candidate)
## 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 ;
- explicite l'héritage des métadonnées et lints Cargo, ainsi que les exceptions locales motivées ;

6
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 5 -->
<!-- version: 6 -->
# 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 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.
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`.
## Entrées principales
@@ -26,7 +26,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
- [`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/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 actif des templates et audits `0.0.3` ;
- [`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/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
## Langue et nomenclature

4
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Roadmap Project Governance Rules
@@ -11,7 +11,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 ;
- `( ) 0.0.3` — templates techniques initiaux et premiers patterns d'audit réutilisables issus de besoins réels ;
- `(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 ;
- `( ) 0.0.5` — réconciliation réelle de PGR avec `khadhroony-solana-project` et `sasedev-games`.

2
VERSION
View File

@@ -1 +1 @@
0.0.3-rc.1
0.0.3

116
deltas/0.0.3/rel.001.md Normal file
View File

@@ -0,0 +1,116 @@
<!-- file: deltas/0.0.3/rel.001.md -->
<!-- version: 1 -->
# Delta 0.0.3 rel.001 — promotion stable pré-tag
## Baseline et version
Baseline : `0.0.3-rc.1`, avec `history/0.0.3/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
Version avant application :
```text
0.0.3-rc.1
```
Version après application :
```text
0.0.3
```
`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.3`. La tranche finalise la présentation de la release, marque la roadmap terminée, retire la mention « candidate » du changelog et clôt le plan comme référence historique. Le prompt `004`, les règles, les modèles, les audits et les tests sont ceux validés en RC : aucune fonctionnalité, règle ou preuve post-tag nouvelle n'est introduite.
La validation de cette tranche est **pré-tag**. Ni le tag `v0.0.3` ni une archive téléchargée depuis Gitea ni un rapport `publish.001` ne sont déclarés existants par ce delta. Ils suivent le history PASS, le commit stable et la publication du tag.
## Scope
REPLACE :
```text
VERSION
README.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
```
ADD :
```text
deltas/0.0.3/rel.001.md
```
DELETE : aucun.
L'archive contient uniquement ces fichiers complets. `history/0.0.3/rc.1.md` arrive séparément ; le history de `rel.001` sera rédigé après sa gate. Le rapport post-tag sera hors de 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.3'
git cat-file -e HEAD:history/0.0.3/rc.1.md
test -f history/0.0.3/rc.1.md
test -f deltas/0.0.3/rel.001.md
test -f prompts/004-V0_0_4_START_PROMPT.md
test ! -e history/0.0.3/rel.001.md
grep -Fx '<!-- version: 6 -->' README.md
grep -Fx '<!-- version: 4 -->' ROADMAP.md
grep -Fx '<!-- version: 5 -->' CHANGELOG.md
grep -Fx '<!-- version: 4 -->' docs/000-README.md
grep -Fx '<!-- version: 9 -->' docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
grep -F 'La release `0.0.3` fournit les premiers modèles Rust/Cargo' README.md
grep -F 'plan historique des templates et audits `0.0.3`' README.md
grep -F -- '- `(x) 0.0.3`' ROADMAP.md
grep -Fx '## 0.0.3' CHANGELOG.md
grep -F 'La gate opérateur de `rc.1` est `PASS`' docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
grep -F "La vérification de l'archive" docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
python3 -B - <<'PY'
from pathlib import Path
import re
names = ['alpha.1', 'alpha.1.fix.1', 'alpha.2', 'alpha.3',
'alpha.4', 'alpha.5', 'alpha.6', 'beta.1', 'rc.1']
for name in names:
history = Path(f'history/0.0.3/{name}.md')
assert Path(f'deltas/0.0.3/{name}.md').is_file(), name
assert re.search(r'## Statut\s+PASS\s', history.read_text(encoding='utf-8')), name
assert {p.stem for p in Path('deltas/0.0.3').glob('*.md')} - \
{p.stem for p in Path('history/0.0.3').glob('*.md')} == {'rel.001'}
print(f'Stable history audit: clean ({len(names)} PASS histories, 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/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md deltas/0.0.3/rel.001.md
git diff --cached --check
git status --short
```
Scope attendu avant ajout du history : six `REPLACE` et un `ADD` exactement comme ci-dessus. Revue opérateur : confirmer que le scope RC ne change pas, que la présentation du dépôt, le changelog et la roadmap décrivent la même stable, que le prompt `004` reste conditionnel au rapport post-tag et que les snapshots historiques restent intacts. Les `15` tests et les cinq TOML validés en RC restent des preuves utilisables parce qu'aucun code, script, test ou template n'a changé dans cette promotion.
## Transition
### PASS
Rédiger et livrer séparément `history/0.0.3/rel.001.md` avec le résultat réellement observé ; l'appliquer et committer la stable. Ensuite seulement, créer et publier le tag canonique `v0.0.3`, télécharger son archive source depuis Gitea, vérifier cette archive et conserver séparément la preuve post-tag `publish.001`. Le texte manuel du prompt `004` n'est remis à l'opérateur qu'après vérification de l'archive et d'un rapport post-tag PASS réel.
### FAIL
Consigner le diagnostic dans le history de `rel.001`, ne pas tagger, puis corriger la clôture dans une tranche explicite avant publication.

4
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Documentation PGR
@@ -20,7 +20,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
## Points d'entrée de 0.0.3
- [`plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — périmètre et trajectoire de la release active ;
- [`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` ;
- [`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.

6
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
<!-- version: 8 -->
<!-- version: 9 -->
# Plan 0.0.3 — templates initiaux et audits réutilisables
@@ -144,12 +144,14 @@ Geler le scope, préparer le changelog et le prompt de la version suivante si la
La gate opérateur de `beta.1` est `PASS` : `15` tests ciblés, trois audits Markdown, chaîne des sept histories alpha et cinq TOML vérifiés. Son résultat détaillé appartient à `history/0.0.3/beta.1.md`. À l'entrée de `rc.1`, le scope est gelé sur les cinq fichiers Rust/Cargo avec leurs deux guides techniques, la spécification du message manuel, les deux audits de style Rust facultatifs et l'audit des headers Markdown. Les règles et scripts antérieurs restent en place ; aucun profil technologique nouveau, générateur ou skeleton complet n'entre dans cette release.
La RC prépare une entrée candidate `0.0.3` dans le changelog et le prompt `004` de `0.0.4`. La première tranche de cette future version décidera des skeleton specifications réellement justifiées après audit de la stable publiée. L'entrée candidate ne devient une entrée de release publiée qu'à la promotion stable ; le rapport post-tag reste une preuve ultérieure distincte. La gate de `rc.1` et son history sont encore à obtenir.
La RC a préparé une entrée candidate `0.0.3` dans le changelog et le prompt `004` de `0.0.4`. La gate opérateur de `rc.1` est `PASS` : `15` tests, trois audits Markdown, chaîne des huit histories précédents et cinq TOML vérifiés. Son résultat détaillé appartient à `history/0.0.3/rc.1.md`. La première tranche de `0.0.4` décidera des skeleton specifications réellement justifiées après audit de la stable publiée ; son rapport post-tag reste une preuve ultérieure distincte.
### stable — 0.0.3
Promouvoir la RC validée, produire le history de clôture pré-tag, committer et tagger, puis contrôler séparément l'archive du tag publiée.
Le delta `rel.001` prépare mécaniquement la version stable `0.0.3` : `VERSION`, statut de la roadmap, présentation du dépôt et des index, et conversion de l'entrée candidate du changelog en entrée stable. Ce plan devient une référence historique à la clôture, sans ajout de règle, profil, template ou audit. Le résultat réel de la gate pré-tag appartient à `history/0.0.3/rel.001.md`, fourni après exécution opérateur ; commit et tag `v0.0.3` suivent uniquement un PASS. La vérification de l'archive effectivement publiée depuis le tag constitue ensuite une preuve post-tag séparée, typiquement `publish.001`, et ne doit pas être présumée par le history pré-tag.
## Points de décision et validation
Le résultat `SPLIT` de `alpha.3` répond à la découverte post-gate de contrôles de style Rust utiles mais mêlés dans deux scripts de référence. Le plan doit encore être revu si les manifests Cargo exigent des choix de projet incompatibles avec un modèle minimal, si l'audit de headers ne peut rester fiable et monotâche, si le template de workflow duplique le plan, ou si un autre examen des corpus révèle des contraintes nouvelles. Un REPLAN explicite indique `CONTINUE`, `SPLIT`, `CONTINUE-NEXT-SESSION` ou `ABANDON` ; la durée d'une conversation ne crée pas une nouvelle version.

50
history/0.0.3/rel.001.md Normal file
View File

@@ -0,0 +1,50 @@
<!-- file: history/0.0.3/rel.001.md -->
<!-- version: 1 -->
# History 0.0.3 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.3`. Ce résultat porte sur l'état du dépôt avant le commit et le tag stables ; il ne valide pas l'archive téléchargée ensuite depuis Gitea.
## Baseline et version
L'opérateur a confirmé `VERSION = 0.0.3`, la présence dans `HEAD` de `history/0.0.3/rc.1.md` par `git cat-file -e`, la présence de ce history, du delta stable et du prompt `004`, ainsi que l'absence du présent history avant sa livraison. Les révisions attendues sont `6` pour `README.md`, `4` pour `ROADMAP.md`, `5` pour `CHANGELOG.md`, `4` pour l'index `docs/` et `9` pour le plan.
La présentation de la release dans `README.md`, le statut `(x)` de `0.0.3` dans la roadmap, l'entrée `## 0.0.3` du changelog, le statut historique du plan et la séparation du contrôle post-tag ont été vérifiés par les commandes de la gate.
## Validation opérateur observée
La vérification des deltas et histories antérieurs a affiché :
```text
Stable history audit: clean (9 PASS histories, rel.001 pending)
```
Les trois audits Markdown ont affiché :
```text
Markdown header audit: clean (98 file(s))
Markdown table audit: clean (3 table(s), 98 file(s))
Markdown link audit: clean (79 local link(s), 98 file(s))
```
`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 :
```text
M CHANGELOG.md
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.3/rel.001.md
M docs/000-README.md
M docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
```
Le collage du terminal intercale un fragment de commande dans la sortie de l'audit des tableaux ; son résultat final `clean` et les autres résultats restent lisibles. Les tests et la syntaxe des modèles TOML validés en RC n'ont pas été rejoués dans cette gate documentaire ; aucun code, script, test ni modèle technique ne change pendant `rel.001`.
## Transition
Appliquer ce history puis committer la stable. Ensuite seulement, créer et publier le tag `v0.0.3`, télécharger l'archive source associée depuis Gitea et exécuter une vérification post-tag séparée. Le commit stable, le tag, la publication et le résultat de cette vérification ne sont pas attestés par la transcription reçue ; aucun statut `publish.001` ne peut encore être consigné.