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

0.1.5-rc.1.fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-10-01 10:55:57 +02:00
parent 4d7021b101
commit f49fd117ac
6 changed files with 318 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
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: 6 -->
<!-- version: 7 -->
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
@@ -289,6 +289,19 @@ Le prompt `012-V0_1_6_START_PROMPT.md` prépare donc une reprise `0.1.6-alpha.1`
La RC ne commence ni l'adoption Games, ni KSP, ni les audits `0.1.8`.
## Gate `rc.1` en échec documentaire et correctif `rc.1.fix.1`
La gate opérateur de `rc.1` du `2026-10-01` conserve les `55/55` tests `PASS`, les audits documentaires propres, le freeze des owners et le scope Git attendu, mais trois assertions textuelles exactes du delta n'ont produit aucune correspondance. Le history `history/0.1.5/rc.1.md` enregistre donc le résultat réel `FAIL`.
Le correctif `rc.1.fix.1` est borné à la présentation documentaire :
- employer dans `CHANGELOG.md` la formule canonique `forte recommandation non obligatoire` attendue par la gate ;
- rendre explicite dans la revue d'horizon que `aucun numéro de version Games n’est figé` ;
- matérialiser la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` dans cette même étude ;
- ne modifier aucun owner normatif, skeleton, template, contrat de validation, roadmap, handoff `012` ou history antérieur.
`rel.1` reste bloqué tant que `rc.1.fix.1` n’est pas validé `PASS`.
## Trajectoire de release
### `alpha.1` — intake, audit transversal et plan

6
docs/studies/005-V0_1_5_HORIZON_REVIEW.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/005-V0_1_5_HORIZON_REVIEW.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Revue d’horizon 0.1.5 — adoption Games après stabilisation des contrats transversaux
@@ -51,7 +51,7 @@ La future session `0.1.6` doit disposer de deux baselines autoritaires distincte
1. la stable PGR `v0.1.5` réellement publiée et vérifiée post-tag ;
2. une archive récente et explicitement autoritaire de `sasedev-games`, fournie comme corpus d’adoption.
Aucun numéro de version Games n’est figé par cette étude. Le corpus Games doit être celui réellement fourni au démarrage de la session ; ne pas reconstruire ou supposer une baseline à partir d’un ancien historique PGR.
Cette revue confirme qu’aucun numéro de version Games n’est figé par cette étude. Le corpus Games doit être celui réellement fourni au démarrage de la session ; ne pas reconstruire ou supposer une baseline à partir d’un ancien historique PGR.
L’absence d’un corpus Games autoritaire empêche de commencer l’adoption réelle, mais n’autorise pas à inventer ses décisions, son architecture ou son applicabilité technologique.
@@ -59,7 +59,7 @@ L’absence d’un corpus Games autoritaire empêche de commencer l’adoption r
`0.1.6` doit commencer par un audit, pas par une réécriture globale.
Pour chaque règle, profil, skeleton, template ou validation PGR potentiellement applicable, la session doit décider explicitement :
Pour chaque règle, profil, skeleton, template ou validation PGR potentiellement applicable, la session doit décider explicitement. La classification canonique est `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` :
```text
ADOPT intégré dans la baseline locale Games