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

0.0.3-rc.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-24 13:22:43 +02:00
parent 47114fa96b
commit ec3a101d9b
6 changed files with 219 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
CHANGELOG.md
View File

@@ -1,5 +1,5 @@
<!-- file: CHANGELOG.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# 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.3 (candidate)
- 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 ;
- ajoute deux audits facultatifs et ciblés du style Rust, pour l'espacement des lignes vides et les blocs de constantes racine sans ordre sémantique, sans remplacer Rustfmt ni Clippy ;
- ajoute un audit read-only des headers `file` et `version` des fichiers Markdown gouvernés par PGR ;
- fournit une spécification courte pour rédiger le message manuel de reprise après publication d'une stable.
## 0.0.2
- introduit le modèle de profils PGR avec ownership normatif, applicabilité, composition du général vers le spécifique et overrides bornés ;

2
VERSION
View File

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

117
deltas/0.0.3/rc.1.md Normal file
View File

@@ -0,0 +1,117 @@
<!-- file: deltas/0.0.3/rc.1.md -->
<!-- version: 1 -->
# Delta 0.0.3-rc.1 — gel du scope et préparation de release
## Baseline et version
Baseline : `0.0.3-beta.1`, avec `history/0.0.3/beta.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
Version avant application :
```text
0.0.3-beta.1
```
Version après application :
```text
0.0.3-rc.1
```
## Objet et gel
La gate de `beta.1` est `PASS`. La RC gèle le scope fonctionnel : cinq modèles Rust/Cargo adaptables, deux audits facultatifs de style Rust, un audit de headers Markdown et une spécification du message manuel de reprise. La candidate `0.0.3` du changelog décrit ces résultats sans détailler les fixes ; le plan enregistre le gel et l'état observé de beta.
Le prompt `004` prépare le cadrage de `0.0.4` consacré aux skeleton specifications Markdown et à la composition des profils/templates. Il demande un audit de la future archive taggée `v0.0.3` et traite son rapport post-tag comme une preuve conditionnelle, jamais acquise en RC. Son message manuel doit être ajusté et remis après la publication et son contrôle réel. Aucun skeleton complet, générateur, règle normative nouvelle, audit nouveau ni projet source modifié n'appartient à `rc.1`.
## Scope
REPLACE :
```text
VERSION
CHANGELOG.md
docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
```
ADD :
```text
prompts/004-V0_0_4_START_PROMPT.md
deltas/0.0.3/rc.1.md
```
DELETE : aucun.
L'archive contient exactement ces fichiers complets. Le history `beta.1` est livré séparément ; le history `rc.1` sera produit après la gate opérateur. Les histories et deltas antérieurs, les règles, modèles techniques, scripts, tests et `ROADMAP.md` restent inchangés.
## Gate opérateur de release candidate
Après application sur le commit `beta.1`, depuis la racine du dépôt :
```bash
test "$(cat VERSION)" = '0.0.3-rc.1'
git cat-file -e HEAD:history/0.0.3/beta.1.md
test -f history/0.0.3/beta.1.md
test -f deltas/0.0.3/rc.1.md
test -f prompts/004-V0_0_4_START_PROMPT.md
test ! -e history/0.0.3/rc.1.md
grep -Fx '<!-- version: 4 -->' CHANGELOG.md
grep -Fx '## 0.0.3 (candidate)' CHANGELOG.md
grep -Fx '<!-- version: 8 -->' docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
grep -F 'La gate opérateur de `beta.1` est `PASS`' docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
grep -F 'pgr-0.0.3-publish.001-report.md' prompts/004-V0_0_4_START_PROMPT.md
grep -F "Si le rapport manque ou n'est pas PASS" prompts/004-V0_0_4_START_PROMPT.md
python3 -B -m unittest discover -s tests -p 'test_*.py' -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
names = ['alpha.1', 'alpha.1.fix.1', 'alpha.2', 'alpha.3',
'alpha.4', 'alpha.5', 'alpha.6', 'beta.1']
version = '0.0.2'
for name in names:
delta = Path(f'deltas/0.0.3/{name}.md').read_text(encoding='utf-8')
history = Path(f'history/0.0.3/{name}.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history), name
assert f'Version avant application : `{version}`.' in delta or \
f'Version avant application :\n\n```text\n{version}\n```' in delta, name
version = f'0.0.3-{name}'
assert f'Version après application : `{version}`.' in delta or \
f'Version après application :\n\n```text\n{version}\n```' in delta, 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')} == {'rc.1'}
for path in Path('templates/rust-cargo').rglob('*.toml'):
tomllib.loads(path.read_text(encoding='utf-8'))
print(f'RC integration audit: clean ({len(names)} PASS histories, 5 TOML files)')
PY
git diff --check
git add VERSION CHANGELOG.md docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md \
prompts/004-V0_0_4_START_PROMPT.md deltas/0.0.3/rc.1.md
git diff --cached --check
git status --short
```
Scope attendu avant ajout du history : trois `REPLACE` et deux `ADD`. Revue opérateur : contrôler que le changelog décrit la release et non les tranches, que les exemples Cargo restent adaptables, que `004` concerne exclusivement la future `0.0.4` et que sa preuve post-tag n'est pas présumée. Une gate RC PASS n'est pas un tag ni une vérification de l'archive publiée.
## Transition
### PASS
Produire séparément `history/0.0.3/rc.1.md` d'après la gate observée, l'appliquer puis committer la RC avant la promotion stable `rel.001`.
### FAIL
Consigner les échecs dans le history RC et corriger le scope gelé dans `rc.1.fix.1` ; réviser le plan si un changement fonctionnel plus large s'impose.

10
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: 7 -->
<!-- version: 8 -->
# Plan 0.0.3 — templates initiaux et audits réutilisables
@@ -134,14 +134,18 @@ La comparaison des prompts `002` et `003` confirme une répétition utile à fac
Vérifier ownership, navigation, séparation règle/template/audit, absence de versions universelles arbitraires et proportion des contrôles. Aucun nouveau domaine majeur sans REPLAN.
La revue préparatoire de cette tranche constate que les sept deltas `0.0.3` de `alpha.1` à `alpha.6`, fix inclus, forment une chaîne de versions continue depuis `0.0.2` et possèdent chacun un history `PASS` fondé sur la gate opérateur ; `beta.1` n'a pas encore de history. Les propriétaires restent distincts : profil `510` pour les conventions Rust facultatives, règles `210` et `300` pour workflow et headers, documents de `docs/templates/` pour l'adaptation, scripts monotâches pour les contrôles. Leurs validations ciblées ont été acquises dans les tranches précédentes ; `beta.1` vérifie leur intégration et la navigation sans exiger de nouveau build des projets sources.
La revue préparatoire de cette tranche a constaté que les sept deltas `0.0.3` de `alpha.1` à `alpha.6`, fix inclus, forment une chaîne de versions continue depuis `0.0.2` et possèdent chacun un history `PASS` fondé sur la gate opérateur. Les propriétaires restent distincts : profil `510` pour les conventions Rust facultatives, règles `210` et `300` pour workflow et headers, documents de `docs/templates/` pour l'adaptation, scripts monotâches pour les contrôles. Leurs validations ciblées avaient été acquises dans les tranches précédentes ; `beta.1` a vérifié leur intégration et la navigation sans exiger de nouveau build des projets sources.
Trois écarts documentaires justifient le delta : l'index de `docs/` présentait tous ses templates comme techniques alors que le troisième décrit la reprise de session ; le plan désignait toujours les headers Markdown comme candidat après leur livraison ; la matrice réservait l'audit de liens à `beta/RC/stable` alors que les gates `alpha` l'emploient également sur des changements de navigation. L'index racine ne pointait pas vers le plan actif. Ces renvois sont corrigés dans les documents vivants sans modifier les snapshots ni les choix de version `0.1.0` et d'édition `2024` explicitement présentés comme exemples adaptables dans les manifests et instructions Rust/Cargo. Le résultat de la gate `beta.1` reste à constater par son history séparé.
Trois écarts documentaires justifiaient le delta : l'index de `docs/` présentait tous ses templates comme techniques alors que le troisième décrit la reprise de session ; le plan désignait toujours les headers Markdown comme candidat après leur livraison ; la matrice réservait l'audit de liens à `beta/RC/stable` alors que les gates `alpha` l'emploient également sur des changements de navigation. L'index racine ne pointait pas vers le plan actif. Ces renvois ont été corrigés dans les documents vivants sans modifier les snapshots ni les choix de version `0.1.0` et d'édition `2024` explicitement présentés comme exemples adaptables dans les manifests et instructions Rust/Cargo.
### rc.1 — gate de release candidate
Geler le scope, préparer le changelog et le prompt de la version suivante si la trajectoire est confirmée ; exécuter la gate documentaire et les vérifications ciblées des scripts réellement ajoutés.
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.
### 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.

41
history/0.0.3/rc.1.md Normal file
View File

@@ -0,0 +1,41 @@
<!-- file: history/0.0.3/rc.1.md -->
<!-- version: 1 -->
# History 0.0.3-rc.1 — gel du scope et préparation de release
## Statut
PASS
La gate de release candidate `rc.1` exécutée par l'opérateur le `2026-09-24` confirme le gel du périmètre, l'entrée candidate du changelog, le prompt `004` et l'intégration documentaire.
## Baseline et version
L'opérateur a confirmé `VERSION = 0.0.3-rc.1`, la présence dans `HEAD` de `history/0.0.3/beta.1.md` par `git cat-file -e`, la présence de ce history, du delta RC et du prompt `004`, ainsi que l'absence du history RC avant cette livraison. Les révisions internes attendues sont `4` pour `CHANGELOG.md` et `8` pour le plan. Le changelog porte l'intitulé `0.0.3 (candidate)` ; le prompt prévoit le rapport post-tag seulement si son résultat réel est PASS.
## Validation opérateur observée
`python3 -B -m unittest discover -s tests -p 'test_*.py' -v` a exécuté `15` tests, tous `ok`, et s'est terminé par `OK`. Les audits ont affiché :
```text
Markdown header audit: clean (96 file(s))
Markdown table audit: clean (3 table(s), 96 file(s))
Markdown link audit: clean (79 local link(s), 96 file(s))
RC integration audit: clean (8 PASS histories, 5 TOML files)
```
`git diff --check` et `git diff --cached --check` n'ont affiché aucun diagnostic. Le statut indexé observé après ajout des fichiers du delta est :
```text
M CHANGELOG.md
M VERSION
A deltas/0.0.3/rc.1.md
M docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
A prompts/004-V0_0_4_START_PROMPT.md
```
Le collage du terminal intercale des fragments de commandes et la sortie des tests ; les résumés `OK`, les résultats finaux des audits et le statut Git restent lisibles. Aucun échec n'est signalé.
## Transition
Appliquer ce history puis committer `rc.1` avant le delta stable `rel.001`. Le commit futur n'est pas attesté par la transcription fournie. Ce PASS n'atteste ni la promotion stable, ni le tag `v0.0.3`, ni le contrôle de l'archive publiée après le tag.

44
prompts/004-V0_0_4_START_PROMPT.md Normal file
View File

@@ -0,0 +1,44 @@
<!-- file: prompts/004-V0_0_4_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.0.4 — spécifications de skeletons
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.0.4` est l'archive source téléchargée depuis le tag Gitea `v0.0.3`, dont le nom attendu est `pgr-v0.0.3.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.4`. Première tranche attendue : `0.0.4-alpha.1`.
Si un rapport séparé `pgr-0.0.3-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.
## Reprise manuelle après publication
Après vérification réelle de l'archive du tag 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 attendus ci-dessus sont confirmés et le rapport est PASS, le texte est :
```text
Partir de l'archive pgr-v0.0.3.zip téléchargée depuis le tag Gitea v0.0.3 et du rapport post-tag pgr-0.0.3-publish.001-report.md. Lire et exécuter prompts/004-V0_0_4_START_PROMPT.md. Vérifier l'archive, les règles, la gouvernance, la structure documentaire, les deltas/histories et la cohérence globale avant de préparer 0.0.4-alpha.1.
```
Si le rapport manque ou n'est pas PASS, supprimer sa mention de la phrase et transmettre son état réel séparément. Adapter les noms à ceux des fichiers effectivement téléchargés. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag, jamais comme attestation anticipée au stade RC.
## Mission
Définir les premières skeleton specifications Markdown réutilisables et les règles pratiques de composition des profils, templates et choix propres au projet. Un skeleton décrit une procédure de sélection, les fichiers et profils applicables, les décisions à prendre et une validation proportionnée ; il ne génère pas automatiquement un projet et ne fixe pas son architecture pour toujours.
`alpha.1` MUST vérifier entièrement la stable `v0.0.3`, en particulier les règles `200` à `610`, les cinq modèles Rust/Cargo, les trois audits Markdown, les deux audits de style Rust facultatifs, la chaîne de deltas/histories et les limites annoncées. Elle doit établir quels skeletons répondent déjà à un besoin concret et lesquels exigent encore des templates ou des décisions préalables. Planifier ensuite les tranches proportionnées de `0.0.4` avant toute matérialisation importante.
## Principes de conception
- Conserver un propriétaire normatif unique par règle et une copie autonome des règles/configurations pertinentes dans chaque projet instancié.
- Respecter la séparation : règles applicables sous `docs/rules/`, fichiers techniques copiables sous `templates/`, mode d'adaptation sous `docs/templates/`, spécifications de skeletons Markdown et audits read-only pour les propriétés réellement contrôlables.
- Sélectionner seulement les profils et templates justifiés par le type de projet ; documenter explicitement le nom, la version, les cibles, les dépendances et les exceptions qui dépendent du destinataire.
- Ne pas déclarer universelles les valeurs `0.1.0`, `2024`, les seuils Clippy ou les chemins d'exemple des templates Rust/Cargo.
- Préserver les décisions d'ordre sémantique des constantes : l'audit correspondant n'est pas une gate globale de tout workspace Rust.
- Différer les skeletons Java/Android, Web, JNI, Tauri et autres familles dont les pièces nécessaires ou les propriétaires manquent encore ; un nouveau domaine demande un cadrage justifié.
- Garder les audits ciblés et non redondants avec les outils officiels ; les tests prouvent des comportements utiles, sans quota arbitraire de couverture.
## 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. Un changement de session ne crée pas une version nouvelle. Un rapport de publication post-tag est séparé de la validation pré-tag.