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

0.1.5

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-10-01 11:02:04 +02:00
parent f49fd117ac
commit ea82a2ed46
8 changed files with 337 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: 21 -->
<!-- version: 22 -->
# 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.1.5 (candidate)
## 0.1.5
- clarifie la sémantique normative de PGR : `MUST / MUST NOT` restent obligatoires, `SHOULD / SHOULD NOT` expriment explicitement une forte recommandation non obligatoire et `MAY` reste une possibilité neutre ;
- aligne l’adoption et la validation afin qu’un simple écart à un `SHOULD / SHOULD NOT` ne crée à lui seul ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` ou justification obligatoire ;

8
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 33 -->
<!-- version: 34 -->
# Project Governance Rules
@@ -11,9 +11,9 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
## Statut
La stable autoritaire courante reste `0.1.4`. La candidate `0.1.5-rc.1` gèle désormais les trois contrats transversaux réconciliés : `SHOULD / SHOULD NOT` reste une forte recommandation non obligatoire, la baseline locale d’un projet devient son autorité après instanciation/adoption avec réalignement PGR uniquement explicite, et PGR reste auto-suffisant face aux contenus pratiques externes possibles de SaseDev Knowledge. La revue d’horizon limitée confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption Games : `0.1.6` reste la prochaine release, suivie de KSP `0.1.7` puis des audits Rust/Clippy `0.1.8`, sans réservation de `0.1.9`.
La stable autoritaire courante est `0.1.5`. Elle stabilise les trois contrats transversaux réconciliés : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, la baseline locale d’un projet devient son autorité après instanciation/adoption avec réalignement PGR uniquement explicite, et PGR reste auto-suffisant face aux contenus pratiques externes possibles de SaseDev Knowledge. La revue d’horizon de clôture confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption Games : `0.1.6` reste la prochaine release, suivie de KSP `0.1.7` puis des audits Rust/Clippy `0.1.8`, sans réservation de `0.1.9`.
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 release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release `0.1.4` stabilise le domaine Tauri : owner `710` recentré sur host/orchestration/ACL/plugins, skeleton `004` composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers `0.1.5` pour clarifier la sémantique normative et l’autonomie des projets.
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 release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release `0.1.4` stabilise le domaine Tauri : owner `710` recentré sur host/orchestration/ACL/plugins, skeleton `004` composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers `0.1.5` pour clarifier la sémantique normative et l’autonomie des projets. La release `0.1.5` stabilise la sémantique `MUST / SHOULD / MAY`, l’autorité de la baseline locale après adoption et le réalignement PGR volontaire, ainsi que la frontière PGR / SaseDev Knowledge ; elle conserve Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` comme scopes distincts.
## Entrées principales
@@ -34,7 +34,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
- [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable Android `0.1.3`, fondée sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
- [`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable Tauri `0.1.4`, du réexamen Games/KSP au skeleton `004`, à la décision d’artefacts et à la revue d’horizon ;
- [`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge et réconciliation transversale avant les adoptions Games/KSP ;
- [`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan historique de la stable `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation transversale et handoff vers l’adoption Games `0.1.6` ;
- [`docs/skeletons/004-TAURI.md`](docs/skeletons/004-TAURI.md) — specialization Tauri 2 composable, sans template technique universel ni defaults de capabilities/plugins/fenêtres/bundles ;
- [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
- [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;

4
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md -->
<!-- version: 18 -->
<!-- version: 19 -->
# Roadmap Project Governance Rules
@@ -27,7 +27,7 @@ La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec
- `(x) 0.1.2` — réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ;
- `(x) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
- `(x) 0.1.4` — domaine Tauri : réexamen du `DEFER`, consolidation de l’owner `710`, matérialisation du skeleton contrôlé `004` et décision explicite de ne pas créer d’artefacts techniques redondants ;
- `( ) 0.1.5` — sémantique normative et autonomie : clarifier `MUST / SHOULD / MAY`, rendre explicite l’autorité locale d’un projet après instanciation/adoption et fixer la frontière durable entre PGR et SaseDev Knowledge ;
- `(x) 0.1.5` — sémantique normative et autonomie : clarifier `MUST / SHOULD / MAY`, rendre explicite l’autorité locale d’un projet après instanciation/adoption et fixer la frontière durable entre PGR et SaseDev Knowledge ;
- `( ) 0.1.6` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, après stabilisation du contrat d’autonomie ;
- `( ) 0.1.7` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
- `( ) 0.1.8` — audits Python read-only d’un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.

2
VERSION
View File

@@ -1 +1 @@
0.1.5-rc.1.fix.1
0.1.5

156
deltas/0.1.5/rel.1.md Normal file
View File

@@ -0,0 +1,156 @@
<!-- file: deltas/0.1.5/rel.1.md -->
<!-- version: 1 -->
# Delta 0.1.5 rel.1 — promotion stable pré-tag
## Baseline et version
Baseline : `0.1.5-rc.1.fix.1`, avec `history/0.1.5/rc.1.fix.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
Version avant application :
```text
0.1.5-rc.1.fix.1
```
Version après application :
```text
0.1.5
```
`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
## Objet
Promouvoir mécaniquement la RC corrigée vers la stable `0.1.5` sans rouvrir les trois contrats stabilisés et sans commencer `0.1.6`.
La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `011` historique.
Aucun owner normatif, skeleton, template, audit Python, étude d'horizon ou prompt de reprise n'est modifié par `rel.1`.
La validation de cette tranche est **pré-tag**. Le tag `v0.1.5`, son archive source Gitea et le rapport `pgr-0.1.5-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.5` et la publication réelle du tag.
## Scope
REPLACE :
```text
VERSION
README.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
```
ADD :
```text
deltas/0.1.5/rel.1.md
```
DELETE : aucun.
Le history `rc.1.fix.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
## Validation opérateur pré-tag
Après application sur le commit contenant `history/0.1.5/rc.1.fix.1.md` :
```bash
cat VERSION
test -f history/0.1.5/rc.1.fix.1.md
test -f deltas/0.1.5/rel.1.md
test -f prompts/012-V0_1_6_START_PROMPT.md
test -f docs/studies/005-V0_1_5_HORIZON_REVIEW.md
test ! -e history/0.1.5/rel.1.md
grep -Fx '0.1.5' VERSION
grep -A2 '^## Statut$' history/0.1.5/rc.1.md | grep -Fx 'FAIL'
grep -A2 '^## Statut$' history/0.1.5/rc.1.fix.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 34 -->' README.md
grep -F 'La stable autoritaire courante est `0.1.5`' README.md
grep -F 'La release `0.1.5` stabilise la sémantique `MUST / SHOULD / MAY`' README.md
grep -F 'plan historique de la stable `0.1.5`' README.md
grep -Fx '<!-- version: 22 -->' CHANGELOG.md
grep -Fx '## 0.1.5' CHANGELOG.md
! grep -Fx '## 0.1.5 (candidate)' CHANGELOG.md
grep -F 'forte recommandation non obligatoire' CHANGELOG.md
grep -Fx '<!-- version: 19 -->' ROADMAP.md
grep -F -- '- `(x) 0.1.5`' ROADMAP.md
grep -F -- '- `( ) 0.1.6`' ROADMAP.md
grep -F -- '- `( ) 0.1.7`' ROADMAP.md
grep -F -- '- `( ) 0.1.8`' ROADMAP.md
! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
grep -Fx '<!-- version: 53 -->' docs/000-README.md
grep -F 'plan historique de la stable `0.1.5`' docs/000-README.md
grep -F 'prompts/012-V0_1_6_START_PROMPT.md' docs/000-README.md
grep -Fx '<!-- version: 8 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -F 'Gate `rc.1.fix.1` acquise et promotion stable' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -F 'Le plan devient historique avec la stable `0.1.5`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -F 'pgr-0.1.5-publish.001-report.md' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -Fx '<!-- version: 16 -->' RULES.md
grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.md
grep -Fx '<!-- version: 2 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.md
python3 -B -c "from pathlib import Path; import re; expected={'alpha.1.md':'PARTIAL','alpha.1.fix.1.md':'PASS','alpha.2.md':'PASS','alpha.3.md':'PASS','alpha.4.md':'PASS','beta.1.md':'PASS','rc.1.md':'FAIL','rc.1.fix.1.md':'PASS'}; assert all(Path('deltas/0.1.5',n).is_file() and Path('history/0.1.5',n).is_file() and re.search(rf'## Statut\s+{st}\s',Path('history/0.1.5',n).read_text(encoding='utf-8')) for n,st in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} - {p.name for p in Path('history/0.1.5').glob('*.md')} == {'rel.1.md'}; print('0.1.5 rel.1 stable gate audit: clean (8 prior histories including alpha.1 PARTIAL and rc.1 FAIL/fix PASS, rel.1 pending)')"
python3 -B -c "from pathlib import Path; s=Path('CHANGELOG.md').read_text(encoding='utf-8').split('## 0.1.5',1)[1].split('## 0.1.4',1)[0]; assert all(x not in s for x in ('alpha.1','alpha.2','alpha.3','alpha.4','beta.1','rc.1','rc.1.fix.1','rel.1')); print('0.1.5 stable changelog: clean')"
git diff --exit-code -- history/0.1.4
git diff --exit-code -- RULES.md docs/objectives/001-PROJECT_OBJECTIVES.md docs/architecture/002-GOVERNANCE_ARCHITECTURE.md docs/rules/210-WORKFLOW.md docs/rules/220-SKELETONS.md docs/rules/230-ADOPTION.md docs/rules/300-DOCUMENTATION.md docs/rules/400-VALIDATION.md docs/rules/500-LANGUAGES.md docs/rules/530-TYPESCRIPT.md docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md docs/rules/700-FRAMEWORKS.md docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md docs/skeletons/003-WEB_FRONTEND.md docs/templates/003-NEW_SESSION_PROMPT.md docs/templates/007-EXISTING_PROJECT_ADOPTION.md docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md docs/studies/005-V0_1_5_HORIZON_REVIEW.md prompts/012-V0_1_6_START_PROMPT.md
python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_text_hygiene.py VERSION README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts scripts tests templates .gitignore .settings
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 status --short
git add VERSION README.md ROADMAP.md CHANGELOG.md deltas/0.1.5/rel.1.md docs/000-README.md docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
git diff --cached --check
git status --short
```
## Scope Git attendu
```text
M CHANGELOG.md
M README.md
M ROADMAP.md
M VERSION
A deltas/0.1.5/rel.1.md
M docs/000-README.md
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
```
## Transition après PASS
Si cette gate pré-tag est `PASS` :
1. produire `history/0.1.5/rel.1.md` avec les preuves opérateur réelles ;
2. appliquer ce history ;
3. `git add -A`, `git diff --cached --check`, puis committer **`0.1.5`** sans suffixe `rel.1` ;
4. pousser `master` ;
5. vérifier un workspace propre ;
6. créer et pousser le tag annoté `v0.1.5` ;
7. télécharger l'archive Gitea du tag et produire `pgr-0.1.5-publish.001-report.md` après vérification indépendante ;
8. seulement après `publish.001 PASS`, ouvrir `0.1.6` avec `prompts/012-V0_1_6_START_PROMPT.md` et une archive Games récente explicitement autoritaire.

4
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 52 -->
<!-- version: 53 -->
# Documentation PGR
@@ -22,7 +22,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
## Points d'entrée de 0.1.5
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de la candidate `0.1.5` : contrats normatifs/autonomie/Knowledge acquis, réconciliation `beta.1` validée et freeze `rc.1` avec revue d’horizon/handoff.
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan historique de la stable `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation, correctif RC documentaire et handoff vers `0.1.6`.
- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
- [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires réconciliés en `alpha.2` : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, sans `FAIL` de gate ni `OVERRIDE` automatique pour un simple écart.
- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — owners réconciliés en `alpha.3` : baseline locale autoritaire, absence d'upstream PGR implicite et réalignement volontaire fondé sur un snapshot choisi.

21
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
@@ -302,6 +302,25 @@ Le correctif `rc.1.fix.1` est borné à la présentation documentaire :
`rel.1` reste bloqué tant que `rc.1.fix.1` n’est pas validé `PASS`.
## Gate `rc.1.fix.1` acquise et promotion stable
La gate opérateur de `rc.1.fix.1` du `2026-10-01` est `PASS` : les trois assertions documentaires qui avaient fait échouer `rc.1` correspondent désormais, les `55/55` tests passent, les audits d'hygiène/Markdown sont propres et le scope Git est exactement celui du correctif.
Le history `history/0.1.5/rc.1.fix.1.md` conserve ce `PASS` sans modifier le `FAIL` historique de `rc.1`.
`rel.1` peut donc promouvoir mécaniquement la candidate vers la stable `0.1.5`. Cette promotion :
- fixe `VERSION` à `0.1.5` ;
- retire le marqueur `candidate` du changelog ;
- marque `0.1.5` terminé dans la roadmap ;
- présente `README.md`, l'index documentaire et le présent plan comme état stable/historique ;
- conserve `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits comme trajectoire engagée ;
- ne commence aucun scope `0.1.6` et ne réserve aucun `0.1.9`.
Après un history `rel.1` `PASS`, le commit produit MUST être `0.1.5` sans suffixe `rel.1`, puis le tag annoté `v0.1.5` et son archive doivent être publiés et vérifiés indépendamment. Le rapport `pgr-0.1.5-publish.001-report.md` ne peut être produit qu'après cette publication réelle.
Le plan devient historique avec la stable `0.1.5`.
## Trajectoire de release
### `alpha.1` — intake, audit transversal et plan

150
history/0.1.5/rel.1.md Normal file
View File

@@ -0,0 +1,150 @@
<!-- file: history/0.1.5/rel.1.md -->
<!-- version: 1 -->
# PGR 0.1.5 — history `rel.1`
## Statut
PASS
## Objet
Clôture opérateur de la tranche stable `0.1.5-rel.1`.
La tranche promeut la candidate corrigée `0.1.5-rc.1.fix.1` en stable `0.1.5` sans rouvrir les contrats normatifs acquis : sémantique `MUST / SHOULD / MAY`, autonomie de la baseline locale après adoption et frontière PGR / SaseDev Knowledge.
## Baseline opérateur
Le correctif `0.1.5-rc.1.fix.1` avec son history `PASS` a été committé puis publié avant application de `rel.1` :
```text
commit rc.1.fix.1 f49fd11
push 4d7021b..f49fd11 master -> master
```
La version observée pendant la gate stable est :
```text
0.1.5
```
Les résultats historiques de la release restent conservés sans réécriture :
```text
alpha.1 PARTIAL
alpha.1.fix.1 PASS
alpha.2 PASS
alpha.3 PASS
alpha.4 PASS
beta.1 PASS
rc.1 FAIL
rc.1.fix.1 PASS
```
`history/0.1.5/rel.1.md` était absent pendant la gate.
## Présentation stable
PASS :
- `README.md` révision `34` présente `0.1.5` comme stable autoritaire courante ;
- `CHANGELOG.md` révision `22` contient `## 0.1.5` sans marqueur `candidate` et conserve la formulation canonique `forte recommandation non obligatoire` ;
- `ROADMAP.md` révision `19` marque `0.1.5` terminé et conserve `0.1.6`, `0.1.7` et `0.1.8` ouverts, sans réserver `0.1.9` ;
- `docs/000-README.md` révision `53` présente le plan `011` comme plan historique de la stable `0.1.5` et conserve le handoff `012` ;
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` révision `8` enregistre le `PASS` du correctif RC, la promotion stable et l'exigence d'une vérification post-tag avant production de `publish.001` ;
- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` reste en révision `2` ;
- `prompts/012-V0_1_6_START_PROMPT.md` reste en révision `1`.
## Owners et contrats gelés
PASS :
```text
RULES.md version 16
docs/rules/210-WORKFLOW.md version 9
docs/rules/230-ADOPTION.md version 3
docs/rules/300-DOCUMENTATION.md version 5
docs/rules/400-VALIDATION.md version 2
```
Le contrôle `git diff --exit-code` a également confirmé l'absence de modification des objectifs, de l'architecture, des owners, skeletons, templates, de l'étude d'horizon et du prompt `012` explicitement gelés pour la promotion stable.
## Frontière delta/history
Résultat opérateur :
```text
0.1.5 rel.1 stable gate audit: clean (8 prior histories including alpha.1 PARTIAL and rc.1 FAIL/fix PASS, rel.1 pending)
```
La gate confirme que :
- les huit tranches antérieures de `0.1.5` possèdent chacune leur delta et leur history avec le statut réellement observé ;
- `rel.1` est la seule tranche `0.1.5` encore sans history pendant sa validation ;
- `history/0.1.4` reste inchangé ;
- le changelog stable ne contient aucun nom de tranche interne `alpha`, `beta`, `rc` ou `rel` dans l'entrée `0.1.5`.
## Tests Python
Commande :
```text
python3 -B -m unittest discover -s tests -v
```
Résultat :
```text
Ran 55 tests in 0.919s
OK
```
Soit `55/55` PASS.
## Hygiène texte
Résultat :
```text
Text hygiene audit: clean (329 file(s))
```
## Audits Markdown
Résultats :
```text
Markdown header audit: clean (302 file(s))
Markdown table audit: clean (11 table(s), 302 file(s))
Markdown link audit: clean (375 local link(s), 302 file(s))
```
## Git
`git diff --check` puis `git diff --cached --check` n'ont remonté aucune anomalie.
Scope final observé :
```text
M CHANGELOG.md
M README.md
M ROADMAP.md
M VERSION
A deltas/0.1.5/rel.1.md
M docs/000-README.md
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
```
Ce scope correspond exactement à la promotion stable prévue.
## Décision
`0.1.5-rel.1` est validée `PASS`.
La tranche peut être historisée puis matérialisée par le commit stable `0.1.5`. Après push de ce commit, le tag annoté `v0.1.5` peut être créé et publié.
La publication ne sera considérée comme vérifiée qu'après récupération de l'archive source Gitea du tag, contrôle indépendant de son intégrité et rejeu des gates depuis cette archive. Le rapport externe `pgr-0.1.5-publish.001-report.md` ne doit être produit qu'après ces preuves réelles.
## Handoff
La prochaine release engagée reste `0.1.6`, consacrée à l'adoption réelle de `sasedev-games` à partir d'un corpus Games récent et explicitement autoritaire. Elle ne doit pas commencer avant un `publish.001` de `v0.1.5` validé `PASS`.