Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 2e121d84cc | |||
| f49fd117ac | |||
| 4d7021b101 | |||
| ec1a2963f6 | |||
| 43ee26b856 | |||
| 7079b150a8 | |||
| e94b78610d | |||
| 32433caccf | |||
| 90ca422b15 |
11
CHANGELOG.md
11
CHANGELOG.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: CHANGELOG.md -->
|
||||
<!-- version: 19 -->
|
||||
<!-- version: 22 -->
|
||||
|
||||
# Changelog Project Governance Rules
|
||||
|
||||
@@ -7,6 +7,15 @@ 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
|
||||
|
||||
- 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 ;
|
||||
- formalise l’autonomie après instanciation/adoption : la baseline locale et ses owners deviennent l’autorité des sessions/releases suivantes, tandis qu’un réalignement PGR futur reste une opération explicite et bornée fondée sur un snapshot choisi ;
|
||||
- fixe la frontière PGR / SaseDev Knowledge : PGR reste auto-suffisant pour ses contrats normatifs, tandis que howtos, recettes, snippets, exemples, dépannage et variantes pratiques peuvent vivre dans une base de connaissances séparée sans devenir une dépendance de PGR ;
|
||||
- réconcilie transversalement les owners concernés sans réécriture mécanique des recommandations existantes et corrige la référence vivante à l’adoption Games vers `0.1.6` ;
|
||||
- confirme par revue d’horizon que l’adoption réelle de `sasedev-games` reste la cible `0.1.6`, suivie de KSP `0.1.7` puis des audits Rust/Clippy `0.1.8`, sans réserver `0.1.9`.
|
||||
|
||||
## 0.1.4
|
||||
|
||||
- réexamine le `DEFER` historique du skeleton Tauri contre les corpus Games/KSP fournis, confirme les prérequis Web désormais couverts et lève le blocage sans généraliser les choix locaux de ces projets ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 27 -->
|
||||
<!-- version: 34 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -11,9 +11,9 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
## Statut
|
||||
|
||||
PGR a clôturé sa phase de fondation `0.0.x` et dispose désormais d’une suite de baselines stables `0.1.x`. La stable `0.1.4` réexamine le domaine Tauri contre les corpus Games/KSP, consolide l’owner `710`, matérialise le skeleton organisationnel `004-TAURI.md`, confirme qu’aucun template technique ni contrat de validation Tauri séparé n’est justifié et ajoute un audit réutilisable d’hygiène texte. La revue d’horizon de fermeture réserve `0.1.5` à la sémantique normative, à l’autonomie des projets après adoption et à la frontière PGR / SaseDev Knowledge avant les adoptions Games `0.1.6` et KSP `0.1.7`.
|
||||
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,6 +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 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 ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 17 -->
|
||||
<!-- 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`.
|
||||
@@ -41,6 +41,6 @@ Le détail et les conditions de cette séquence sont conservés dans [`docs/stud
|
||||
- `saselang-bible`, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure `0.2.x` / `0.3.x` à décider ;
|
||||
- `deployment & operations` — famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon `0.4.x` ou `0.5.x` est plausible mais aucun numéro précis n'est réservé.
|
||||
|
||||
La revue d’horizon `0.1.4-rc.1` remplace l’ordre initial `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits par le contrat ci-dessus. Une nouvelle revue d’horizon doit intervenir si `0.1.5` démontre que l’autonomie ne peut pas être stabilisée sans scope supplémentaire, ou si Games/KSP exigent un owner réellement préalable à une adoption proportionnée.
|
||||
La revue d’horizon `0.1.4-rc.1` remplace l’ordre initial `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits par le contrat ci-dessus. La revue limitée `0.1.5-rc.1` confirme que les contrats transversaux sont suffisamment stabilisés et qu’aucun nouveau prérequis ne doit précéder l’adoption Games : l’ordre `0.1.6` Games, `0.1.7` KSP, `0.1.8` audits est conservé et aucun `0.1.9` n’est réservé.
|
||||
|
||||
Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`.
|
||||
|
||||
17
RULES.md
17
RULES.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: RULES.md -->
|
||||
<!-- version: 14 -->
|
||||
<!-- version: 16 -->
|
||||
|
||||
# Index normatif Project Governance Rules
|
||||
|
||||
@@ -19,11 +19,11 @@ La gouvernance doit rester proportionnée au risque, à la portée du changement
|
||||
|
||||
PGR utilise les termes suivants :
|
||||
|
||||
- `MUST` / `MUST NOT` : obligation ou interdiction dans le scope de la règle, sauf override ou exception explicitement documenté ;
|
||||
- `SHOULD` / `SHOULD NOT` : comportement attendu par défaut, avec dérogation possible lorsqu'une solution différente est mieux adaptée et justifiée ;
|
||||
- `MAY` : possibilité reconnue, sans obligation implicite.
|
||||
- `MUST` / `MUST NOT` : obligation ou interdiction normative dans le scope de la règle ; une contradiction applicable doit être traitée par l'exception ou l'override autorisé, sinon elle constitue une non-conformité ;
|
||||
- `SHOULD` / `SHOULD NOT` : forte recommandation non obligatoire. Un écart ne constitue pas à lui seul une non-conformité, ne fait pas échouer à lui seul une gate et n'exige pas automatiquement un `OVERRIDE` ; la raison MAY être documentée lorsqu'elle apporte une valeur durable de maintenance, architecture ou reprise ;
|
||||
- `MAY` : possibilité neutre reconnue, sans obligation implicite.
|
||||
|
||||
Une règle qualitative ne doit pas être artificiellement transformée en `MUST` lorsqu'elle n'est ni objectivement vérifiable ni raisonnablement révisable.
|
||||
Une règle qualitative ne doit pas être artificiellement transformée en `MUST` lorsqu'elle n'est ni objectivement vérifiable ni raisonnablement révisable. Une gate, un skeleton, un template ou un profil plus spécifique MUST conserver cette distinction de force normative au lieu de renforcer implicitement un `SHOULD`.
|
||||
|
||||
## Hiérarchie normative
|
||||
|
||||
@@ -45,12 +45,13 @@ project-specific
|
||||
explicit exception
|
||||
```
|
||||
|
||||
Une règle plus spécifique MAY raffiner, renforcer ou remplacer localement une règle générale dans son scope. Une contradiction intentionnelle MUST être déclarée comme override ou exception, avec scope et raison. Une contrainte locale ne se propage jamais automatiquement aux autres projets ou profils.
|
||||
Une règle plus spécifique MAY raffiner ou renforcer localement une règle générale dans son scope. Lorsqu'elle contredit intentionnellement un `MUST` / `MUST NOT` réellement applicable, cette contradiction MUST être déclarée comme override ou exception, avec scope et raison. Un choix différent d'un `SHOULD` / `SHOULD NOT` n'est pas, par lui-même, une contradiction normative exigeant un override. Une contrainte locale ne se propage jamais automatiquement aux autres projets ou profils.
|
||||
|
||||
## Principes fondamentaux
|
||||
|
||||
- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables.
|
||||
- PGR MUST NOT devenir une dépendance runtime ou build des projets qu'il aide à initialiser.
|
||||
- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables. Après établissement de la baseline locale, cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes.
|
||||
- PGR MUST NOT devenir une dépendance runtime, build ou documentaire implicite des projets qu'il aide à initialiser ou adopter. Un projet gouverné localement MUST NOT rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream à suivre.
|
||||
- Un réalignement futur avec PGR MAY être engagé comme opération explicite et bornée : le projet choisit un snapshot PGR précis, compare ce snapshot à sa baseline locale, décide les écarts applicables et conserve ses historiques. Le réalignement ne constitue jamais une mise à jour automatique de la gouvernance locale.
|
||||
- Les skeletons PGR sont des spécifications Markdown et MUST NOT devenir un générateur qui fige l'architecture d'un projet.
|
||||
- Les audits `audit_*.py` MUST être read-only, déterministes autant que raisonnablement possible et sans effets de bord sur le dépôt inspecté.
|
||||
- Une propriété déjà correctement contrôlée par le compilateur, le linter ou le build system SHOULD NOT être dupliquée par un test ou audit maison sans besoin réel.
|
||||
|
||||
125
deltas/0.1.5/alpha.1.fix.1.md
Normal file
125
deltas/0.1.5/alpha.1.fix.1.md
Normal file
@@ -0,0 +1,125 @@
|
||||
<!-- file: deltas/0.1.5/alpha.1.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.1.fix.1 — acquisition des preuves manquantes de la gate d'ouverture
|
||||
|
||||
## Baseline
|
||||
|
||||
Version attendue avant application :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.1
|
||||
```
|
||||
|
||||
Le history `history/0.1.5/alpha.1.md` avec statut `PARTIAL` MUST avoir été appliqué, committé et poussé avant ce delta.
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.1.fix.1
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Résoudre uniquement le résultat `PARTIAL` de `alpha.1` en exécutant les preuves exigées par sa gate mais absentes du transcript opérateur.
|
||||
|
||||
Aucun défaut normatif, documentaire ou structurel n'est établi par `alpha.1`. Le présent fix ne réécrit donc pas son contenu, ne modifie aucun owner et ne commence pas `alpha.2`.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
deltas/0.1.5/alpha.1.fix.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
## Preuves à acquérir
|
||||
|
||||
Le fix doit confirmer dans l'environnement opérateur :
|
||||
|
||||
- la trajectoire vivante `0.1.4` terminé puis `0.1.5` à `0.1.8`, sans réservation `0.1.9` ;
|
||||
- les `103` couples delta/history historiques de `0.0.1` à `0.1.4`, plus le couple `0.1.5-alpha.1` désormais clôturé et le delta courant encore sans history ;
|
||||
- les contrats du prompt `011` sur `SHOULD`, l'autonomie post-adoption et les scopes réservés ;
|
||||
- les constats structurants du plan `011` et la séparation des tranches `alpha.2`, `alpha.3` et `alpha.4` ;
|
||||
- l'hygiène du nouveau delta et le scope Git strictement limité au fix.
|
||||
|
||||
Les `55/55` tests Python, l'hygiène texte et les audits Markdown complets de `alpha.1` sont déjà des preuves opérateur acquises. Le fix ne modifie aucun code ni script ; il ne rejoue donc pas la suite Python par simple répétition. Les audits texte/Markdown sont toutefois rejoués pour valider le nouvel artefact documentaire.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Exécuter depuis la racine du dépôt après commit/push de `alpha.1` puis application du présent delta :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.1.md
|
||||
test -f deltas/0.1.5/alpha.1.fix.1.md
|
||||
test ! -e history/0.1.5/alpha.1.fix.1.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.1.fix.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
|
||||
grep -F -- '- `(x) 0.1.4`' ROADMAP.md
|
||||
grep -F -- '- `( ) 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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md'}; print('0.1.5 alpha.1.fix.1 history boundary: clean (104 closed prior pairs, current fix pending)')"
|
||||
|
||||
grep -F 'forte recommandation non obligatoire' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'ne doivent ni rechercher automatiquement « la dernière version de PGR »' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.6`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.7`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservés à `0.1.8`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
|
||||
grep -F '29` fichiers' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '242` occurrences' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '### `alpha.2` — sémantique normative et conséquences de gate/adoption' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '### `alpha.3` — autonomie locale et réalignement volontaire' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '### `alpha.4` — frontière PGR / SaseDev Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 deltas/0.1.5/alpha.1.fix.1.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history du fix est :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.fix.1.md
|
||||
```
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.5/alpha.1.fix.1.md`, appliquer ce history puis committer/pusher `0.1.5-alpha.1.fix.1`. Préparer ensuite `0.1.5-alpha.2` conformément au plan, sans réouvrir les scopes autonomie `alpha.3` ou Knowledge `alpha.4`.
|
||||
|
||||
### FAIL / PARTIAL / BLOCKED
|
||||
|
||||
Consigner le résultat réellement observé dans `history/0.1.5/alpha.1.fix.1.md` et rester dans `alpha.1.fix.M` tant que les preuves d'ouverture ne sont pas complètement acquises, sauf REPLAN si un défaut plus large est démontré.
|
||||
222
deltas/0.1.5/alpha.1.md
Normal file
222
deltas/0.1.5/alpha.1.md
Normal file
@@ -0,0 +1,222 @@
|
||||
<!-- file: deltas/0.1.5/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.1 — intake, audit transversal et plan d’autonomie
|
||||
|
||||
## Objet
|
||||
|
||||
Ouvrir `0.1.5` conformément à `prompts/011-V0_1_5_START_PROMPT.md`, rejouer la stable `0.1.4`, conserver son histoire réelle et matérialiser l’inventaire des ambiguïtés avant toute modification normative.
|
||||
|
||||
La tranche ne modifie aucune règle, aucun skeleton ni template normatif. Elle ne commence ni l’adoption Games `0.1.6`, ni l’adoption KSP `0.1.7`, ni les audits Rust/Clippy `0.1.8`.
|
||||
|
||||
## Sources vérifiées avant préparation
|
||||
|
||||
```text
|
||||
pgr-v0.1.4(1).zip
|
||||
SHA-256 9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
|
||||
CRC PASS
|
||||
contenu 310 fichiers + 44 répertoires sous pgr/
|
||||
|
||||
pgr-0.1.4-publish.001-report.md
|
||||
SHA-256 bb0c27a69e78037328d13c7be8df255d17f55e1392f1bc1b6121dd32b6fb07da
|
||||
status PASS
|
||||
stable c41b69badfd10ef9500d4cc4061fc6f66644352c
|
||||
```
|
||||
|
||||
Le SHA de l’archive reçue correspond au SHA canonique vérifié lors de la publication post-tag. L’absence de `.git` dans l’archive est normale pour l’export du tag et n’est pas interprétée comme un défaut.
|
||||
|
||||
## Replay de la stable
|
||||
|
||||
La baseline extraite a été vérifiée avant toute préparation de delta :
|
||||
|
||||
```text
|
||||
VERSION 0.1.4
|
||||
tests Python 55/55 PASS
|
||||
hygiène texte 309 fichiers PASS
|
||||
headers Markdown 282 fichiers PASS
|
||||
tables Markdown 11 tables / 282 fichiers PASS
|
||||
liens Markdown 357 liens locaux / 282 fichiers PASS
|
||||
JSON 2 fichiers parsés
|
||||
TOML 5 fichiers parsés
|
||||
deltas 103
|
||||
histories 103
|
||||
appariement historique exact
|
||||
```
|
||||
|
||||
La séquence `0.1.4` publiée est explicitement conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 FAIL
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
Aucun history n’est réécrit pour rendre la chronologie artificiellement linéaire.
|
||||
|
||||
## Résultats de l’audit transversal
|
||||
|
||||
Le corpus courant contient `29` fichiers avec au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences brutes. Cette volumétrie confirme qu’une conversion mécanique serait incorrecte : la majorité des recommandations restent valides et doivent hériter d’un contrat global clarifié.
|
||||
|
||||
Les ambiguïtés confirmées sont consignées dans `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`.
|
||||
|
||||
### Force normative
|
||||
|
||||
- `RULES.md` peut faire comprendre qu’un écart à `SHOULD` doit être systématiquement justifié ;
|
||||
- `230-ADOPTION.md` peut faire comprendre qu’un choix différent d’un `SHOULD` nécessite automatiquement `OVERRIDE` ;
|
||||
- `400-VALIDATION.md` ne protège pas encore explicitement une gate contre l’échec fondé sur le seul écart à une recommandation ;
|
||||
- plusieurs owners Web matérialisent cette ambiguïté par une justification ou un `OVERRIDE` rendu obligatoire autour d’une recommandation.
|
||||
|
||||
### Autonomie
|
||||
|
||||
Les objectifs, l’architecture, les skeletons et les patterns d’adoption contiennent déjà le principe d’autonomie, mais le contrat « baseline locale = autorité des sessions/releases suivantes » n’est pas encore propagé explicitement partout. PGR doit aussi cesser d’être interprétable comme upstream documentaire vivant après l’adoption.
|
||||
|
||||
`210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` sont classés `KEEP / REVIEW` à ce stade : ils utilisent déjà la baseline autoritaire du projet courant plutôt qu’une version PGR externe.
|
||||
|
||||
### Frontière PGR / Knowledge
|
||||
|
||||
`001-PROJECT_OBJECTIVES.md` et `002-GOVERNANCE_ARCHITECTURE.md` parlent encore de skeletons comme de « recettes Markdown ». Cette terminologie brouille la frontière décidée en `0.1.4`, où les recettes pratiques deviennent des candidats à Knowledge tandis qu’un skeleton PGR reste une spécification de composition.
|
||||
|
||||
`300-DOCUMENTATION.md` est proposé comme owner de la taxonomie ; aucun nouvel owner Knowledge n’est créé pendant `alpha.1`.
|
||||
|
||||
### Cohérence d’horizon
|
||||
|
||||
`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` contient encore une référence vivante à l’adoption Games `0.1.5`. La trajectoire autoritaire issue de la revue `0.1.4` réserve maintenant Games à `0.1.6`, KSP à `0.1.7` et les audits Rust/Clippy à `0.1.8`.
|
||||
|
||||
La correction appartient à la réconciliation normative suivante. Les références historiques qui décrivent correctement un horizon antérieur ne doivent pas être réécrites.
|
||||
|
||||
## Modifications de la tranche
|
||||
|
||||
- `VERSION` passe à `0.1.5-alpha.1` ;
|
||||
- `README.md` annonce l’ouverture de l’audit transversal et référence le plan actif ;
|
||||
- `docs/000-README.md` ajoute les points d’entrée actifs de `0.1.5` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` consigne preuves, ambiguïtés, owners et trajectoire ;
|
||||
- le présent delta décrit la gate opérateur.
|
||||
|
||||
`ROADMAP.md`, `CHANGELOG.md`, `RULES.md`, `docs/rules/`, `docs/skeletons/` et `docs/templates/` restent normativement inchangés pendant cette tranche d’ouverture.
|
||||
|
||||
## Décision de tranche
|
||||
|
||||
```text
|
||||
baseline 0.1.4 VERIFIED
|
||||
history 0.1.4 alpha.2 FAIL PRESERVED
|
||||
inventaire transversal COMPLETE
|
||||
conversion mécanique des SHOULD REJECTED
|
||||
owners ciblés IDENTIFIED
|
||||
règles modifiées en alpha.1 NO
|
||||
Games / KSP / audits Rust commencés NO
|
||||
prochaine tranche alpha.2 — sémantique normative et gates/adoption
|
||||
```
|
||||
|
||||
## Trajectoire retenue
|
||||
|
||||
```text
|
||||
alpha.1 intake + audit transversal + plan
|
||||
alpha.2 sémantique MUST/SHOULD/MAY + gates/adoption + cas concrets
|
||||
alpha.3 autonomie locale + réalignement PGR volontaire
|
||||
alpha.4 frontière PGR / SaseDev Knowledge
|
||||
beta.1 réconciliation transversale
|
||||
rc.1 freeze + handoff
|
||||
rel.1 promotion stable
|
||||
```
|
||||
|
||||
Le découpage peut être ajusté uniquement si une gate révèle un défaut réel ou si deux owners ne peuvent pas être corrigés proprement dans la même tranche.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Appliquer le delta puis exécuter depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
test -f deltas/0.1.5/alpha.1.md
|
||||
test ! -e history/0.1.5/alpha.1.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.4/alpha.2.md | grep -Fx 'FAIL'
|
||||
grep -A2 '^## Statut$' history/0.1.4/alpha.2.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.4/rel.1.md | grep -Fx 'PASS'
|
||||
|
||||
grep -F -- '- `(x) 0.1.4`' ROADMAP.md
|
||||
grep -F -- '- `( ) 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
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert Path('deltas/0.1.5/alpha.1.md').is_file(); assert not Path('history/0.1.5/alpha.1.md').exists(); print('0.1.5 alpha.1 history boundary: clean (103 prior pairs, current delta pending)')"
|
||||
|
||||
grep -F 'forte recommandation non obligatoire' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'ne doivent ni rechercher automatiquement « la dernière version de PGR »' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.6`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.7`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
grep -F 'réservés à `0.1.8`' prompts/011-V0_1_5_START_PROMPT.md
|
||||
|
||||
grep -F '29` fichiers' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '242` occurrences' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.2` — sémantique normative' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.3` — autonomie locale' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'alpha.4` — frontière PGR / SaseDev Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
|
||||
git diff --check
|
||||
git status --short
|
||||
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
deltas/0.1.5/alpha.1.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Aucun fichier sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` ne doit être indexé pour `alpha.1`.
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer que l’inventaire distingue bien :
|
||||
|
||||
- un `SHOULD` réellement recommandatoire d’une obligation `MUST` ;
|
||||
- un choix local face à une recommandation d’un véritable `OVERRIDE` ;
|
||||
- l’autonomie documentaire du projet d’une simple absence de dépendance runtime/build ;
|
||||
- une skeleton specification normative d’une recette pratique candidate à Knowledge ;
|
||||
- les références vivantes à corriger des références historiques à préserver.
|
||||
|
||||
Elle doit également confirmer qu’aucune adoption Games/KSP, aucun audit Rust futur et aucune réouverture Tauri ne sont introduits par la tranche.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.5/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, préparer séparément le delta `0.1.5-alpha.2` consacré à la sémantique normative, aux conséquences de gate/adoption et aux cas concrets déjà identifiés, sans absorber l’autonomie `alpha.3` ni la frontière Knowledge `alpha.4`.
|
||||
|
||||
Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.5-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history, puis ouvrir `0.1.5-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.
|
||||
196
deltas/0.1.5/alpha.2.md
Normal file
196
deltas/0.1.5/alpha.2.md
Normal file
@@ -0,0 +1,196 @@
|
||||
<!-- file: deltas/0.1.5/alpha.2.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.2 — sémantique normative et conséquences de gate/adoption
|
||||
|
||||
## Objet
|
||||
|
||||
Stabiliser la force normative de `MUST / SHOULD / MAY` après le cadrage `alpha.1` et la récupération de preuve `alpha.1.fix.1`, puis corriger uniquement les renforcements accidentels démontrés par l'inventaire.
|
||||
|
||||
La tranche ne convertit pas mécaniquement les `242` occurrences de `SHOULD / SHOULD NOT`. Elle fixe le contrat transversal, aligne adoption et validation, puis corrige les quelques owners/skeletons/templates où une recommandation était implicitement transformée en obligation de justification ou en `OVERRIDE`.
|
||||
|
||||
## Précondition
|
||||
|
||||
Le history `history/0.1.5/alpha.1.fix.1.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence d'ouverture reste conservée telle qu'observée :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
```
|
||||
|
||||
Le `PARTIAL` n'est pas réécrit : le fix a seulement acquis les preuves manquantes et autorise maintenant la progression vers la sémantique normative.
|
||||
|
||||
## Contrat normatif stabilisé
|
||||
|
||||
`RULES.md` devient l'owner primaire de la distinction :
|
||||
|
||||
```text
|
||||
MUST / MUST NOT obligation ou interdiction normative
|
||||
SHOULD / SHOULD NOT forte recommandation non obligatoire
|
||||
MAY possibilité neutre
|
||||
```
|
||||
|
||||
Un écart à un `SHOULD / SHOULD NOT` PGR :
|
||||
|
||||
- ne constitue pas à lui seul une non-conformité ;
|
||||
- ne fait pas échouer à lui seul une gate ;
|
||||
- n'exige pas automatiquement un `OVERRIDE` ;
|
||||
- MAY être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.
|
||||
|
||||
Une contradiction avec un `MUST / MUST NOT` réellement applicable reste distincte et continue d'utiliser l'exception ou l'override autorisé par le scope concerné.
|
||||
|
||||
## Alignement adoption et validation
|
||||
|
||||
`docs/rules/230-ADOPTION.md` passe en révision `2` : la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ne renforce plus implicitement un `SHOULD`. Un simple choix différent d'une recommandation ne devient pas un `OVERRIDE` obligatoire.
|
||||
|
||||
`docs/rules/400-VALIDATION.md` passe en révision `2` : une gate doit distinguer obligation et recommandation. Un `SHOULD` non suivi peut produire une observation, un diagnostic ou un point de revue, mais pas un `FAIL` par sa seule force PGR. Un projet peut rendre localement un choix obligatoire uniquement en matérialisant explicitement ce contrat local.
|
||||
|
||||
## Réconciliation ciblée des effets `SHOULD`
|
||||
|
||||
Les owners et artefacts suivants sont corrigés parce que `alpha.1` a démontré un renforcement concret :
|
||||
|
||||
- `docs/rules/500-LANGUAGES.md` révision `2` : un override est requis pour une contradiction réelle avec un `MUST / MUST NOT`, pas pour un simple écart à un `SHOULD` ;
|
||||
- `docs/rules/530-TYPESCRIPT.md` révision `4` : choisir JavaScript malgré la recommandation TypeScript ne crée ni non-conformité, ni override, ni justification obligatoire ;
|
||||
- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` révision `4` : la politique de lockfile reste une recommandation lorsqu'elle est marquée `SHOULD`, et la référence vivante Games est corrigée de `0.1.5` vers `0.1.6` ;
|
||||
- `docs/rules/700-FRAMEWORKS.md` révision `3` : la composition conserve la force normative propre des règles héritées au lieu de traiter toute divergence comme override ;
|
||||
- `docs/skeletons/003-WEB_FRONTEND.md` révision `2` : un choix JavaScript n'impose plus de justification automatique ;
|
||||
- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` révision `3` : une politique de lockfile différente n'exige plus automatiquement `OVERRIDE` + justification.
|
||||
|
||||
Les `MUST` réellement applicables de ces documents restent inchangés dans leur intention.
|
||||
|
||||
## Cohérence documentaire
|
||||
|
||||
- `README.md` présente `0.1.5-alpha.2` comme la tranche active sans déclarer la stable `0.1.4` remplacée ;
|
||||
- `docs/000-README.md` marque les owners de sémantique comme réconciliés en `alpha.2` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `2`, conserve les constats `alpha.1` comme observations historiques et enregistre la récupération `alpha.1.fix.1` ainsi que la mise en œuvre `alpha.2`.
|
||||
|
||||
`ROADMAP.md` et `CHANGELOG.md` restent inchangés. Les histories `0.1.4`, les adoptions Games/KSP et les futurs audits Rust/Clippy restent hors scope.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Appliquer le delta après commit/push de `alpha.1.fix.1`, puis exécuter depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.1.md
|
||||
test -f history/0.1.5/alpha.1.fix.1.md
|
||||
test -f deltas/0.1.5/alpha.2.md
|
||||
test ! -e history/0.1.5/alpha.2.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.2' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 15 -->' RULES.md
|
||||
grep -F 'forte recommandation non obligatoire' RULES.md
|
||||
grep -F "n'exige pas automatiquement un \`OVERRIDE\`" RULES.md
|
||||
grep -F "ne fait pas échouer à lui seul une gate" RULES.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/230-ADOPTION.md
|
||||
grep -F "ne crée pas à lui seul un \`OVERRIDE\` obligatoire" docs/rules/230-ADOPTION.md
|
||||
grep -F 'MUST NOT exiger un override uniquement parce que la recommandation' docs/rules/230-ADOPTION.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.md
|
||||
grep -F 'MUST NOT faire passer une tranche en `FAIL`' docs/rules/400-VALIDATION.md
|
||||
grep -F "la gate évalue alors ce contrat local, pas le \`SHOULD\` PGR d'origine" docs/rules/400-VALIDATION.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/500-LANGUAGES.md
|
||||
grep -F "Un choix différent d'un \`SHOULD / SHOULD NOT\` général ne nécessite pas, à lui seul, un override" docs/rules/500-LANGUAGES.md
|
||||
|
||||
grep -Fx '<!-- version: 4 -->' docs/rules/530-TYPESCRIPT.md
|
||||
grep -F "n'exige pas automatiquement un \`OVERRIDE\` et ne crée pas une obligation de justification" docs/rules/530-TYPESCRIPT.md
|
||||
! grep -F 'sauf incompatibilité documentée' docs/rules/530-TYPESCRIPT.md
|
||||
|
||||
grep -Fx '<!-- version: 4 -->' docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
grep -F "Lors de l'adoption \`0.1.6\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
! grep -F "Lors de l'adoption \`0.1.5\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
grep -F "ne requiert pas à lui seul un \`OVERRIDE\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/700-FRAMEWORKS.md
|
||||
grep -F "MAY choisir différemment d'un \`SHOULD / SHOULD NOT\`" docs/rules/700-FRAMEWORKS.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/skeletons/003-WEB_FRONTEND.md
|
||||
grep -F "sans transformer un choix JavaScript en obligation de justification ou en \`OVERRIDE\`" docs/skeletons/003-WEB_FRONTEND.md
|
||||
|
||||
grep -Fx '<!-- version: 3 -->' docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
|
||||
grep -F "n'exige pas à lui seul un \`OVERRIDE\` ni une justification" docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md'}; print('0.1.5 alpha.2 history boundary: clean (105 closed prior pairs, current alpha.2 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 RULES.md docs/000-README.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
docs/rules/230-ADOPTION.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/003-WEB_FRONTEND.md docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md \
|
||||
deltas/0.1.5/alpha.2.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.2.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/230-ADOPTION.md
|
||||
M docs/rules/400-VALIDATION.md
|
||||
M docs/rules/500-LANGUAGES.md
|
||||
M docs/rules/530-TYPESCRIPT.md
|
||||
M docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
M docs/rules/700-FRAMEWORKS.md
|
||||
M docs/skeletons/003-WEB_FRONTEND.md
|
||||
M docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
|
||||
```
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer que la tranche clarifie la force de `SHOULD` sans affaiblir les obligations existantes ; qu'aucun `SHOULD` n'est transformé en `MUST` par une gate, un mapping d'adoption, un skeleton ou un template ; et que les corrections Web ciblées restent des conséquences de la sémantique générale plutôt qu'une réouverture de la fondation Web.
|
||||
|
||||
Elle doit également confirmer que l'autonomie post-adoption n'est pas encore implémentée par `alpha.2`, que la frontière PGR / Knowledge n'est pas encore modifiée, et que les scopes `0.1.6` à `0.1.8` restent réservés.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.5/alpha.2.md` à partir des résultats réellement observés. Dans la même réponse, fournir les commandes commit/push de `0.1.5-alpha.2`, puis préparer séparément `0.1.5-alpha.3` consacré à l'autonomie locale et au réalignement PGR volontaire.
|
||||
|
||||
### FAIL / PARTIAL / BLOCKED
|
||||
|
||||
Enregistrer le résultat réel dans `history/0.1.5/alpha.2.md` puis ouvrir `alpha.2.fix.N` ou un REPLAN selon la cause. Aucun changement réservé à l'autonomie `alpha.3` ou à la frontière Knowledge `alpha.4` ne doit être absorbé silencieusement dans la correction.
|
||||
185
deltas/0.1.5/alpha.3.md
Normal file
185
deltas/0.1.5/alpha.3.md
Normal file
@@ -0,0 +1,185 @@
|
||||
<!-- file: deltas/0.1.5/alpha.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.3 — autonomie locale et réalignement PGR volontaire
|
||||
|
||||
## Objet
|
||||
|
||||
Stabiliser le contrat d'autonomie après instanciation ou adoption : une fois la baseline locale établie, le projet gouverne ses sessions et releases suivantes depuis ses propres owners, sans dépendance documentaire implicite vers PGR ni recherche automatique d'une version plus récente du référentiel.
|
||||
|
||||
La tranche définit également le seul mécanisme prévu pour revenir volontairement vers PGR : un réalignement explicite, borné, fondé sur un snapshot PGR précis choisi par le projet puis comparé à la baseline locale.
|
||||
|
||||
## Précondition
|
||||
|
||||
Le history `history/0.1.5/alpha.2.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence acquise reste conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
```
|
||||
|
||||
Le `PARTIAL` initial n'est pas réécrit et les histories précédents restent inchangés.
|
||||
|
||||
## Contrat d'autonomie
|
||||
|
||||
Après instanciation ou adoption :
|
||||
|
||||
```text
|
||||
snapshot PGR explicitement choisi
|
||||
↓
|
||||
instanciation / adoption / adaptation
|
||||
↓
|
||||
baseline locale du projet
|
||||
↓
|
||||
autorité locale des sessions et releases suivantes
|
||||
```
|
||||
|
||||
Le projet possède alors ses règles, plans, architecture, décisions et historiques applicables. PGR ne devient ni dépendance runtime/build, ni upstream documentaire implicite.
|
||||
|
||||
Le projet MUST NOT rechercher automatiquement « la dernière version de PGR » pour reprendre une session ou ouvrir une release suivante.
|
||||
|
||||
## Réalignement futur
|
||||
|
||||
Un réalignement PGR reste possible lorsqu'il est explicitement décidé. Il ne constitue pas une mise à jour continue.
|
||||
|
||||
L'opération doit :
|
||||
|
||||
1. identifier un snapshot PGR précis — version, tag, commit ou archive ;
|
||||
2. repartir de la baseline locale autoritaire ;
|
||||
3. comparer les owners PGR réellement applicables ;
|
||||
4. classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
5. définir un scope et des validations proportionnés ;
|
||||
6. préserver les histories et snapshots historiques du projet.
|
||||
|
||||
Entre deux réalignements explicitement décidés, la baseline locale reste suffisante et autoritaire.
|
||||
|
||||
## Owners réconciliés
|
||||
|
||||
- `RULES.md` révision `16` : autonomie générale, absence d'upstream PGR implicite et réalignement borné ;
|
||||
- `docs/rules/220-SKELETONS.md` révision `2` : la baseline locale devient autoritaire dès l'instanciation et aucune version PGR plus récente n'est recherchée automatiquement ;
|
||||
- `docs/rules/230-ADOPTION.md` révision `3` : contrat complet d'autorité locale et procédure de réalignement futur ;
|
||||
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : propagation du contrat au point d'entrée normatif local ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : snapshot PGR choisi, baseline locale de sortie et pattern de réalignement explicite.
|
||||
|
||||
`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` restent `KEEP` : leur reprise part déjà de la baseline autoritaire du projet courant et aucune contradiction n'a été démontrée.
|
||||
|
||||
## Cohérence documentaire
|
||||
|
||||
- `README.md` présente `0.1.5-alpha.3` comme tranche active ;
|
||||
- `docs/000-README.md` identifie les owners d'autonomie réconciliés ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `3`, enregistre `alpha.2 PASS` et la mise en œuvre `alpha.3`.
|
||||
|
||||
`ROADMAP.md` et `CHANGELOG.md` restent inchangés. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4` ; Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `alpha.2` avec son history `PASS`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.2.md
|
||||
test -f deltas/0.1.5/alpha.3.md
|
||||
test ! -e history/0.1.5/alpha.3.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.3' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 16 -->' RULES.md
|
||||
grep -F 'cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes' RULES.md
|
||||
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' RULES.md
|
||||
grep -F 'réalignement futur avec PGR MAY être engagé comme opération explicite et bornée' RULES.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/220-SKELETONS.md
|
||||
grep -F 'Cette baseline locale devient l'autorité de ses sessions et releases suivantes' docs/rules/220-SKELETONS.md
|
||||
grep -F 'MUST NOT rechercher automatiquement une version PGR plus récente' docs/rules/220-SKELETONS.md
|
||||
grep -F "snapshot PGR précis choisi par le projet" docs/rules/220-SKELETONS.md
|
||||
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
|
||||
grep -F 'elle devient l'autorité des sessions et releases suivantes du projet' docs/rules/230-ADOPTION.md
|
||||
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/rules/230-ADOPTION.md
|
||||
grep -F '## Autorité locale et réalignement futur' docs/rules/230-ADOPTION.md
|
||||
grep -F 'identifier le snapshot PGR choisi' docs/rules/230-ADOPTION.md
|
||||
grep -F 'Le réalignement ne doit pas être présenté comme une mise à jour automatique' docs/rules/230-ADOPTION.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
grep -F "la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes" docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
grep -F 'snapshot PGR choisi' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
grep -F '## Autorité après adoption' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
grep -F 'réalignement PGR automatique : non' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
grep -F 'Elles ne recherchent pas automatiquement « la dernière version de PGR »' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
|
||||
grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/templates/003-NEW_SESSION_PROMPT.md
|
||||
|
||||
grep -Fx '<!-- version: 3 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Sa gate opérateur du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Décisions de mise en œuvre `alpha.3`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'la frontière Knowledge reste réservée à `alpha.4`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md'}; print('0.1.5 alpha.3 history boundary: clean (106 closed prior pairs, current alpha.3 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 RULES.md docs/000-README.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
docs/rules/220-SKELETONS.md docs/rules/230-ADOPTION.md \
|
||||
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
|
||||
docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
|
||||
deltas/0.1.5/alpha.3.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.3.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/220-SKELETONS.md
|
||||
M docs/rules/230-ADOPTION.md
|
||||
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
M docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
```
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer qu'un projet adopté reste effectivement gouvernable sans consulter PGR, que le réalignement futur est une opération explicite et non un abonnement implicite, et qu'aucune règle n'oblige un projet à suivre automatiquement les nouvelles releases PGR.
|
||||
|
||||
Elle doit aussi confirmer que `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent corrects sans modification et que `alpha.3` ne commence ni la frontière Knowledge ni les adoptions Games/KSP.
|
||||
186
deltas/0.1.5/alpha.4.md
Normal file
186
deltas/0.1.5/alpha.4.md
Normal file
@@ -0,0 +1,186 @@
|
||||
<!-- file: deltas/0.1.5/alpha.4.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.4 — frontière PGR / SaseDev Knowledge
|
||||
|
||||
## Objet
|
||||
|
||||
Stabiliser la frontière durable entre le référentiel normatif PGR et les contenus pratiques qui peuvent vivre dans une base de connaissances séparée.
|
||||
|
||||
PGR doit rester auto-suffisant pour comprendre et appliquer ses règles. SaseDev Knowledge MAY accueillir des howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation, mais ne devient ni owner normatif de PGR ni dépendance nécessaire à son interprétation.
|
||||
|
||||
La tranche ne déplace aucun contenu vers Knowledge et ne crée aucun lien de dépendance vers un dépôt externe.
|
||||
|
||||
## Précondition
|
||||
|
||||
Le history `history/0.1.5/alpha.3.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence acquise reste conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
```
|
||||
|
||||
Les histories précédents ne sont pas réécrits.
|
||||
|
||||
## Taxonomie stabilisée
|
||||
|
||||
PGR conserve les informations nécessaires à son propre contrat :
|
||||
|
||||
```text
|
||||
PGR
|
||||
règles et contrats de gouvernance
|
||||
objectifs et architecture
|
||||
owners normatifs
|
||||
skeleton specifications minimales
|
||||
templates nécessaires à un contrat réutilisable
|
||||
validations directement liées aux règles
|
||||
```
|
||||
|
||||
Les contenus suivants sont pratiques et MAY vivre dans une base de connaissances séparée :
|
||||
|
||||
```text
|
||||
contenus pratiques complémentaires
|
||||
howtos détaillés
|
||||
recettes pratiques
|
||||
snippets
|
||||
exemples d'intégration
|
||||
dépannage
|
||||
comparatifs
|
||||
variantes d'implémentation
|
||||
```
|
||||
|
||||
Cette classification est sémantique. Elle ne déclenche aucun déplacement automatique.
|
||||
|
||||
## Auto-suffisance
|
||||
|
||||
Une règle PGR doit rester interprétable depuis PGR lui-même. Un document pratique externe MAY aider à l'implémentation, mais MUST NOT être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR.
|
||||
|
||||
SaseDev Knowledge est une destination possible pour les contenus pratiques, pas un upstream normatif. PGR MUST NOT dépendre de sa disponibilité.
|
||||
|
||||
Une extraction physique future exige une destination autoritaire explicitement fournie et vérifiée. `0.1.5-alpha.4` ne réalise aucune migration.
|
||||
|
||||
## Owners réconciliés
|
||||
|
||||
- `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` : remplace « recette Markdown » par « spécification Markdown composable », ajoute l'auto-suffisance PGR et sépare les contenus pratiques externes ;
|
||||
- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` : clarifie la nature du skeleton et formalise la frontière architecturale avec les contenus pratiques externes ;
|
||||
- `docs/rules/300-DOCUMENTATION.md` révision `5` : devient l'owner documentaire de la taxonomie normative/pratique, de l'auto-suffisance et du caractère non automatique d'une extraction future.
|
||||
|
||||
Aucun owner Knowledge supplémentaire n'est créé.
|
||||
|
||||
## Cohérence documentaire
|
||||
|
||||
- `README.md` présente `0.1.5-alpha.4` comme tranche active ;
|
||||
- `docs/000-README.md` présente les trois owners comme réconciliés en `alpha.4` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `4`, enregistre `alpha.3 PASS` et les décisions de mise en œuvre `alpha.4`.
|
||||
|
||||
`RULES.md`, `ROADMAP.md` et `CHANGELOG.md` restent inchangés. Les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `alpha.3` avec son history `PASS`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.3.md
|
||||
test -f deltas/0.1.5/alpha.4.md
|
||||
test ! -e history/0.1.5/alpha.4.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.4' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'spécifications Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation vivent dans une base de connaissances séparée' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
! grep -F 'recettes Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'Un skeleton est une spécification Markdown composable' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F '## Frontière avec les contenus pratiques externes' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'SaseDev Knowledge est une destination possible' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F "MUST NOT dépendre d'un dépôt Knowledge" docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
! grep -F 'Un skeleton est une recette Markdown' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F '## Frontière normative et pratique' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'PGR MUST rester auto-suffisant' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F "MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR" docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'Classifier un contenu comme pratique ne crée pas une obligation de déplacement' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'MUST NOT créer de dépendance de PGR vers SaseDev Knowledge' docs/rules/300-DOCUMENTATION.md
|
||||
|
||||
grep -Fx '<!-- version: 4 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'La gate opérateur de `alpha.3` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Décisions de mise en œuvre `alpha.4`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'ne créer aucun nouvel owner Knowledge' 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 -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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md'}; print('0.1.5 alpha.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
git diff --exit-code -- RULES.md ROADMAP.md CHANGELOG.md docs/rules/210-WORKFLOW.md docs/rules/230-ADOPTION.md
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 docs/000-README.md \
|
||||
docs/objectives/001-PROJECT_OBJECTIVES.md \
|
||||
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
|
||||
docs/rules/300-DOCUMENTATION.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
deltas/0.1.5/alpha.4.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.4.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
M docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
```
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer que la frontière est sémantique et non une dépendance entre dépôts : PGR reste utilisable seul, Knowledge reste une destination pratique possible, aucun contenu n'est déplacé et aucun owner externe n'est requis pour interpréter une règle.
|
||||
|
||||
Elle doit aussi confirmer que la tranche ne modifie pas les contrats d'autonomie acquis en `alpha.3` et ne commence pas les adoptions Games/KSP.
|
||||
169
deltas/0.1.5/beta.1.md
Normal file
169
deltas/0.1.5/beta.1.md
Normal file
@@ -0,0 +1,169 @@
|
||||
<!-- file: deltas/0.1.5/beta.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-beta.1 — réconciliation transversale
|
||||
|
||||
## Objet
|
||||
|
||||
Fermer la phase alpha de `0.1.5` en réconciliant transversalement les trois contrats acquis : sémantique `MUST / SHOULD / MAY`, autonomie de la baseline locale et frontière PGR / SaseDev Knowledge.
|
||||
|
||||
Le rescan préparatoire ne démontre aucun nouveau défaut normatif nécessitant une correction. `beta.1` est donc une tranche d'intégration et de preuve : elle documente les décisions de `KEEP`, rejoue les validations complètes et conserve les scopes futurs hors de la release courante.
|
||||
|
||||
## Préconditions
|
||||
|
||||
Le history `history/0.1.5/alpha.4.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence acquise doit rester :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
alpha.4 PASS
|
||||
```
|
||||
|
||||
Les histories antérieurs ne sont pas réécrits.
|
||||
|
||||
## Réconciliation `SHOULD / SHOULD NOT`
|
||||
|
||||
Le rescan relit les owners vivants où une recommandation cohabite avec un `MUST`, une justification ou une contrainte conditionnelle.
|
||||
|
||||
Les clauses conservées ne renforcent pas le simple écart à `SHOULD / SHOULD NOT` : elles portent une propriété distincte de sécurité, identité, hygiène d'output ou maintenabilité. Les corrections ciblées d'`alpha.2` restent donc suffisantes et aucun owner normatif supplémentaire n'est modifié en `beta.1`.
|
||||
|
||||
Les contrats centraux restent :
|
||||
|
||||
```text
|
||||
SHOULD / SHOULD NOT
|
||||
forte recommandation non obligatoire
|
||||
écart seul != non-conformité
|
||||
écart seul != FAIL de gate
|
||||
écart seul != OVERRIDE obligatoire
|
||||
justification MAY être documentée si elle apporte une valeur durable
|
||||
```
|
||||
|
||||
## Autonomie et snapshots
|
||||
|
||||
La réconciliation confirme que :
|
||||
|
||||
- la baseline locale et ses owners sont l'autorité des sessions/releases suivantes après instanciation/adoption ;
|
||||
- PGR n'est pas un upstream documentaire implicite ;
|
||||
- aucun mécanisme ne recherche automatiquement « la dernière version de PGR » ;
|
||||
- un réalignement futur est une opération explicite et bornée, fondée sur un snapshot PGR choisi ;
|
||||
- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP`.
|
||||
|
||||
## Frontière PGR / Knowledge
|
||||
|
||||
PGR reste auto-suffisant pour déterminer la force, le scope et les exigences de ses règles. SaseDev Knowledge MAY accueillir des contenus pratiques complémentaires, mais ne devient ni owner normatif, ni source requise, ni dépendance de PGR.
|
||||
|
||||
Aucune migration physique n'est réalisée en `beta.1`.
|
||||
|
||||
## Trajectoire réconciliée
|
||||
|
||||
La référence vivante Games dans `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` reste corrigée vers `0.1.6`.
|
||||
|
||||
Les références historiques qui décrivent un ancien horizon restent inchangées lorsqu'elles sont exactes dans leur contexte.
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games RESERVED
|
||||
0.1.7 adoption KSP RESERVED
|
||||
0.1.8 audits Rust/Clippy RESERVED
|
||||
0.1.9 NOT RESERVED
|
||||
```
|
||||
|
||||
`beta.1` ne commence aucun de ces scopes.
|
||||
|
||||
## Modifications
|
||||
|
||||
- `VERSION` passe à `0.1.5-beta.1` ;
|
||||
- `README.md` passe en révision `32` et présente la réconciliation bêta ;
|
||||
- `docs/000-README.md` passe en révision `51` et indexe `beta.1` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `5`, enregistre `alpha.4 PASS` et les résultats du rescan préparatoire ;
|
||||
- aucun owner normatif, skeleton, template, validation, study ou history antérieur n'est modifié.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `alpha.4` avec son history `PASS`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.4.md
|
||||
test -f deltas/0.1.5/beta.1.md
|
||||
test ! -e history/0.1.5/beta.1.md
|
||||
|
||||
grep -Fx '0.1.5-beta.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.4.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 16 -->' RULES.md
|
||||
grep -F 'forte recommandation non obligatoire' RULES.md
|
||||
grep -F "n'exige pas automatiquement un \`OVERRIDE\`" RULES.md
|
||||
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
|
||||
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/rules/230-ADOPTION.md
|
||||
grep -F 'identifier le snapshot PGR choisi' docs/rules/230-ADOPTION.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.md
|
||||
grep -F 'MUST NOT faire passer une tranche en `FAIL`' docs/rules/400-VALIDATION.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'PGR MUST rester auto-suffisant' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR' docs/rules/300-DOCUMENTATION.md
|
||||
|
||||
grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/templates/003-NEW_SESSION_PROMPT.md
|
||||
|
||||
grep -F "Lors de l'adoption \`0.1.6\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
! grep -F "Lors de l'adoption \`0.1.5\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'La gate opérateur de `alpha.4` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Réconciliation transversale préparée en `beta.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'KEEP des owners normatifs acquis' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md'}; print('0.1.5 beta.1 history boundary: clean (108 closed prior pairs, current beta.1 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
git diff --exit-code -- RULES.md ROADMAP.md CHANGELOG.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
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py README.md RULES.md ROADMAP.md CHANGELOG.md VERSION 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 docs/000-README.md docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md deltas/0.1.5/beta.1.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
## Scope Git attendu
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/beta.1.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
## Suite
|
||||
|
||||
Si la gate est `PASS`, produire `history/0.1.5/beta.1.md`, committer/pousser la tranche puis préparer `rc.1` : freeze des contrats stabilisés, présentation candidate, revue d'horizon bornée et préparation du handoff `0.1.6` uniquement si la trajectoire reste valide.
|
||||
165
deltas/0.1.5/rc.1.fix.1.md
Normal file
165
deltas/0.1.5/rc.1.fix.1.md
Normal file
@@ -0,0 +1,165 @@
|
||||
<!-- file: deltas/0.1.5/rc.1.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-rc.1.fix.1 — alignement des assertions documentaires RC
|
||||
|
||||
## Diagnostic
|
||||
|
||||
La gate opérateur de `0.1.5-rc.1` a validé le freeze fonctionnel, les `55/55` tests Python, les audits d'hygiène/Markdown et le scope Git, mais trois assertions exactes prévues par `rc.1` n'ont produit aucune correspondance :
|
||||
|
||||
```text
|
||||
grep -F 'forte recommandation non obligatoire' CHANGELOG.md
|
||||
grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
```
|
||||
|
||||
`history/0.1.5/rc.1.md` enregistre donc `FAIL`.
|
||||
|
||||
Le diagnostic est strictement documentaire : les contrats normatifs, la décision d'horizon, le prompt `012` et les validations techniques restent acquis.
|
||||
|
||||
## Objet
|
||||
|
||||
Aligner les formulations de présentation avec les chaînes canoniques exigées par la gate RC sans rouvrir aucun owner normatif et sans commencer `rel.1` ou `0.1.6`.
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.1.5-rc.1.fix.1
|
||||
```
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
CHANGELOG.md
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
deltas/0.1.5/rc.1.fix.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
`README.md`, `ROADMAP.md`, `docs/000-README.md`, le prompt `012`, tous les owners normatifs, skeletons, templates, validations et histories antérieurs MUST rester inchangés.
|
||||
|
||||
## Corrections
|
||||
|
||||
`CHANGELOG.md` passe en révision `21` et emploie la formulation canonique `forte recommandation non obligatoire` pour `SHOULD / SHOULD NOT`.
|
||||
|
||||
`docs/studies/005-V0_1_5_HORIZON_REVIEW.md` passe en révision `2` et :
|
||||
|
||||
- contient explicitement la sous-chaîne `aucun numéro de version Games n’est figé` ;
|
||||
- expose explicitement la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` avant son détail ligne par ligne.
|
||||
|
||||
`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `7` et conserve la vérité opérateur `rc.1 FAIL` ainsi que le scope borné du présent fix.
|
||||
|
||||
Aucune décision d'horizon n'est modifiée.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `rc.1` avec son history `FAIL`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/rc.1.md
|
||||
test -f deltas/0.1.5/rc.1.fix.1.md
|
||||
test ! -e history/0.1.5/rc.1.fix.1.md
|
||||
|
||||
grep -Fx '0.1.5-rc.1.fix.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/rc.1.md | grep -Fx 'FAIL'
|
||||
|
||||
grep -Fx '<!-- version: 21 -->' CHANGELOG.md
|
||||
grep -F 'forte recommandation non obligatoire' CHANGELOG.md
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'conserver `0.1.6` comme prochaine release' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'Aucun `0.1.9` n’est réservé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
|
||||
grep -Fx '<!-- version: 7 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Gate `rc.1` en échec documentaire et correctif `rc.1.fix.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'history/0.1.5/rc.1.md` enregistre donc le résultat réel `FAIL`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '`rel.1` reste bloqué tant que `rc.1.fix.1` n’est pas validé `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
|
||||
grep -Fx '<!-- version: 33 -->' README.md
|
||||
grep -Fx '<!-- version: 18 -->' ROADMAP.md
|
||||
grep -Fx '<!-- version: 52 -->' docs/000-README.md
|
||||
grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md','rc.1.fix.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md'}; print('0.1.5 rc.1.fix.1 history boundary: clean (110 closed prior pairs, current rc.1.fix.1 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
|
||||
git diff --exit-code -- README.md ROADMAP.md docs/000-README.md \
|
||||
prompts/012-V0_1_6_START_PROMPT.md 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
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 CHANGELOG.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
docs/studies/005-V0_1_5_HORIZON_REVIEW.md \
|
||||
deltas/0.1.5/rc.1.fix.1.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
## Scope Git attendu
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/rc.1.fix.1.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
```
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.5/rc.1.fix.1.md`, committer/pousser `0.1.5-rc.1.fix.1`, puis préparer `rel.1` comme promotion stable mécanique sans nouveau scope.
|
||||
|
||||
### FAIL
|
||||
|
||||
Enregistrer le résultat réel dans `history/0.1.5/rc.1.fix.1.md` et poursuivre sous `rc.1.fix.N`. Ne pas commencer `rel.1` tant que le correctif RC n'est pas `PASS`.
|
||||
207
deltas/0.1.5/rc.1.md
Normal file
207
deltas/0.1.5/rc.1.md
Normal file
@@ -0,0 +1,207 @@
|
||||
<!-- file: deltas/0.1.5/rc.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-rc.1 — freeze, revue d’horizon et handoff Games
|
||||
|
||||
## Objet
|
||||
|
||||
Geler les trois contrats transversaux réconciliés par `beta.1`, préparer la présentation candidate de `0.1.5`, effectuer la revue d’horizon limitée prévue par le plan et préparer le handoff vers `0.1.6` uniquement puisque l’adoption Games reste la prochaine dépendance réelle.
|
||||
|
||||
La RC n’ajoute aucun nouveau contrat normatif et ne commence aucune adoption.
|
||||
|
||||
## Préconditions
|
||||
|
||||
Le history `history/0.1.5/beta.1.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence réelle doit rester :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
alpha.4 PASS
|
||||
beta.1 PASS
|
||||
```
|
||||
|
||||
Les owners stabilisés pendant `alpha.2` à `alpha.4` sont gelés sauf défaut démontré. Aucun défaut nouveau n’est introduit par la préparation RC.
|
||||
|
||||
## Revue d’horizon
|
||||
|
||||
`docs/studies/005-V0_1_5_HORIZON_REVIEW.md` confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption réelle de `sasedev-games`.
|
||||
|
||||
La trajectoire reste :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
0.1.9 NOT RESERVED
|
||||
```
|
||||
|
||||
La revue impose pour `0.1.6` une stable PGR `v0.1.5` réellement publiée/vérifiée et une archive Games récente explicitement autoritaire. Elle ne fige volontairement aucun numéro Games.
|
||||
|
||||
## Handoff 0.1.6
|
||||
|
||||
`prompts/012-V0_1_6_START_PROMPT.md` prépare `0.1.6-alpha.1` comme tranche d’intake et de cartographie avant migration.
|
||||
|
||||
Le prompt exige une classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, conserve la sémantique non obligatoire de `SHOULD / SHOULD NOT`, préserve les décisions locales Games et rappelle que la baseline Games devient l’autorité du projet après adoption.
|
||||
|
||||
Il interdit de généraliser automatiquement un ancien POC ou artefact historique sans applicabilité démontrée par le corpus Games fourni.
|
||||
|
||||
## Modifications
|
||||
|
||||
- `VERSION` passe à `0.1.5-rc.1` ;
|
||||
- `README.md` passe en révision `33` et présente la candidate/freeze ;
|
||||
- `CHANGELOG.md` passe en révision `20` et reçoit l’entrée `0.1.5 (candidate)` sans chronologie de tranches ;
|
||||
- `ROADMAP.md` passe en révision `18` et enregistre la confirmation de trajectoire issue de la revue `0.1.5-rc.1` ;
|
||||
- `docs/000-README.md` passe en révision `52` et indexe la revue d’horizon et le handoff `012` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `6`, enregistre `beta.1 PASS` et le freeze RC ;
|
||||
- `docs/studies/000-README.md` passe en révision `6` ;
|
||||
- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` est créé ;
|
||||
- `prompts/012-V0_1_6_START_PROMPT.md` est créé ;
|
||||
- aucun owner normatif, skeleton, template ou contrat de validation stabilisé par les alphas n’est modifié.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `beta.1` avec son history `PASS`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/beta.1.md
|
||||
test -f deltas/0.1.5/rc.1.md
|
||||
test -f docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
test -f prompts/012-V0_1_6_START_PROMPT.md
|
||||
test ! -e history/0.1.5/rc.1.md
|
||||
|
||||
grep -Fx '0.1.5-rc.1' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.4.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/beta.1.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 33 -->' README.md
|
||||
grep -F 'candidate `0.1.5-rc.1`' README.md
|
||||
grep -F '`0.1.6` reste la prochaine release' README.md
|
||||
|
||||
grep -Fx '<!-- version: 20 -->' CHANGELOG.md
|
||||
grep -Fx '## 0.1.5 (candidate)' CHANGELOG.md
|
||||
grep -F 'forte recommandation non obligatoire' CHANGELOG.md
|
||||
grep -F 'baseline locale et ses owners deviennent l’autorité' CHANGELOG.md
|
||||
grep -F 'SaseDev Knowledge' CHANGELOG.md
|
||||
grep -F 'adoption réelle de `sasedev-games` reste la cible `0.1.6`' CHANGELOG.md
|
||||
|
||||
python3 -B -c "from pathlib import Path; s=Path('CHANGELOG.md').read_text(encoding='utf-8').split('## 0.1.5 (candidate)',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','rel.1')); print('0.1.5 candidate changelog: clean')"
|
||||
|
||||
grep -Fx '<!-- version: 18 -->' ROADMAP.md
|
||||
grep -F -- '- `( ) 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 'La revue limitée `0.1.5-rc.1` confirme' ROADMAP.md
|
||||
! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
|
||||
|
||||
grep -Fx '<!-- version: 52 -->' docs/000-README.md
|
||||
grep -F 'studies/005-V0_1_5_HORIZON_REVIEW.md' docs/000-README.md
|
||||
grep -F 'prompts/012-V0_1_6_START_PROMPT.md' docs/000-README.md
|
||||
|
||||
grep -Fx '<!-- version: 6 -->' docs/studies/000-README.md
|
||||
grep -F '005-V0_1_5_HORIZON_REVIEW.md' docs/studies/000-README.md
|
||||
|
||||
grep -Fx '<!-- version: 1 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'conserver `0.1.6` comme prochaine release' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'Aucun `0.1.9` n’est réservé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
|
||||
grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'tag Gitea `v0.1.5`' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'pgr-0.1.5-publish.001-report.md' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'archive récente et explicitement autoritaire de `sasedev-games`' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F '0.1.6-alpha.1' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'ne doivent pas rechercher automatiquement « la dernière version de PGR »' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'réservée à `0.1.7`' prompts/012-V0_1_6_START_PROMPT.md
|
||||
grep -F 'réservés à `0.1.8`' prompts/012-V0_1_6_START_PROMPT.md
|
||||
|
||||
grep -Fx '<!-- version: 6 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'La gate opérateur de `beta.1` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Freeze et revue d’horizon préparés en `rc.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '0.1.9 NOT RESERVED' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F '012-V0_1_6_START_PROMPT.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
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md'}; print('0.1.5 rc.1 history boundary: clean (109 closed prior pairs, current rc.1 pending)')"
|
||||
|
||||
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
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
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 CHANGELOG.md ROADMAP.md \
|
||||
deltas/0.1.5/rc.1.md \
|
||||
docs/000-README.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
docs/studies/000-README.md \
|
||||
docs/studies/005-V0_1_5_HORIZON_REVIEW.md \
|
||||
prompts/012-V0_1_6_START_PROMPT.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/rc.1.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/studies/000-README.md
|
||||
A docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
A prompts/012-V0_1_6_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Transition
|
||||
|
||||
Si la gate est `PASS`, produire `history/0.1.5/rc.1.md`, committer/pousser `0.1.5-rc.1`, puis préparer `rel.1` comme promotion mécanique vers la stable `0.1.5`, sans rouvrir les contrats acquis ni commencer `0.1.6`.
|
||||
156
deltas/0.1.5/rel.1.md
Normal file
156
deltas/0.1.5/rel.1.md
Normal 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.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 46 -->
|
||||
<!-- version: 53 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -20,6 +20,18 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
|
||||
|
||||
Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
|
||||
|
||||
## 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 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.
|
||||
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners réconciliés en `alpha.4` : PGR reste auto-suffisant pour ses contrats normatifs ; les contenus pratiques externes restent complémentaires, sans dépendance PGR vers Knowledge ni déplacement automatique.
|
||||
- `beta.1` réconcilie les trois contrats sans nouvel owner normatif : les renforcements `SHOULD` connus restent corrigés, `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent compatibles avec l’autonomie locale, et les références vivantes Games/KSP/audits restent respectivement réservées à `0.1.6`, `0.1.7` et `0.1.8`.
|
||||
- [`studies/005-V0_1_5_HORIZON_REVIEW.md`](studies/005-V0_1_5_HORIZON_REVIEW.md) — revue limitée `rc.1` confirmant que l’adoption Games `0.1.6` reste la prochaine dépendance réelle sans nouveau prérequis transversal ni réservation de `0.1.9`.
|
||||
- [`../prompts/012-V0_1_6_START_PROMPT.md`](../prompts/012-V0_1_6_START_PROMPT.md) — handoff préparé vers l’adoption réelle de `sasedev-games` en `0.1.6-alpha.1`, à utiliser uniquement après publication et vérification post-tag de `v0.1.5` avec un corpus Games autoritaire explicitement fourni.
|
||||
- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.
|
||||
|
||||
## Points d'entrée de 0.1.4
|
||||
|
||||
- [`plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.4` : réexamen Tauri, skeleton `004`, décision d’artefacts, freeze RC et revue d’horizon.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Architecture de gouvernance PGR
|
||||
|
||||
@@ -23,7 +23,7 @@ Après instanciation, le projet possède sa copie et ne dépend plus de PGR.
|
||||
|
||||
### Skeleton specification
|
||||
|
||||
Un skeleton est une recette Markdown décrivant comment initialiser un type de projet ou composer plusieurs profils.
|
||||
Un skeleton est une spécification Markdown composable décrivant comment initialiser un type de projet ou composer plusieurs profils.
|
||||
|
||||
Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base. Le contrat transversal de sélection et de composition appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md) ; les spécifications concrètes sont indexées sous [`../skeletons/`](../skeletons/000-README.md).
|
||||
|
||||
@@ -37,6 +37,16 @@ Les scripts `audit_*.py` sont read-only : ils ne modifient, ne formatent, ne gé
|
||||
|
||||
Les audits PGR sont ajoutés progressivement à partir de besoins réels et de contrôles éprouvés. PGR ne cherche pas à anticiper un catalogue exhaustif d'audits.
|
||||
|
||||
## Frontière avec les contenus pratiques externes
|
||||
|
||||
PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs. Les règles, owners, objectifs, décisions architecturales, skeleton specifications, templates nécessaires à un contrat réutilisable et validations directement liées aux règles restent possédés par PGR lorsqu'ils sont nécessaires à cette compréhension.
|
||||
|
||||
Les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation MAY vivre dans une base de connaissances séparée. SaseDev Knowledge est une destination possible pour cette famille de contenus, mais sa disponibilité n'est pas une précondition d'utilisation de PGR.
|
||||
|
||||
Un contenu pratique externe MAY compléter PGR, mais MUST NOT devenir la source nécessaire pour déterminer ce qu'une règle PGR exige. PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
|
||||
|
||||
Cette frontière est sémantique avant d'être physique : classifier un contenu comme pratique ne déclenche pas automatiquement son déplacement. Une extraction future exige une destination autoritaire explicitement fournie et doit préserver dans PGR tout contrat nécessaire à son auto-suffisance.
|
||||
|
||||
## Instanciation d'un projet
|
||||
|
||||
Le flux conceptuel est :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Objectifs de Project Governance Rules
|
||||
|
||||
@@ -18,9 +18,11 @@ PGR doit permettre de :
|
||||
- favoriser des validations ciblées pendant le développement et des gates plus larges aux jalons appropriés ;
|
||||
- automatiser les contrôles déterministes et fiables sans automatiser artificiellement les décisions nécessitant du jugement ;
|
||||
- fournir des templates techniques éprouvés sans créer de dépendance vers PGR après instanciation ;
|
||||
- décrire des skeletons de projets sous forme de recettes Markdown composables plutôt que de générateurs rigides ;
|
||||
- décrire des skeletons de projets sous forme de spécifications Markdown composables plutôt que de générateurs rigides ;
|
||||
- supporter plusieurs langages, plateformes et frameworks sans chercher une uniformité artificielle ;
|
||||
- conserver une traçabilité historique utile tout en gardant les documents vivants lisibles ;
|
||||
- rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR, sans dépendre d’un howto, snippet ou dépôt documentaire externe ;
|
||||
- permettre que les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation vivent dans une base de connaissances séparée lorsqu’une telle séparation apporte une valeur réelle ;
|
||||
- permettre des règles project-specific et des exceptions explicites sans contaminer les règles générales ;
|
||||
- privilégier la sécurité, l'explicité, la maintenabilité et la proportionnalité.
|
||||
|
||||
@@ -45,6 +47,7 @@ PGR n'a pas pour objectif de :
|
||||
- créer des audits regex pour remplacer le jugement architectural ;
|
||||
- réimplémenter les fonctionnalités des toolchains officielles sans bénéfice réel ;
|
||||
- maintenir automatiquement les projets créés à partir de PGR ;
|
||||
- devenir une base exhaustive de howtos, recettes, snippets ou dépannage lorsque ces contenus ne sont pas nécessaires pour comprendre ou appliquer un contrat PGR ;
|
||||
- imposer une stratégie Git complexe ou une topologie universelle de branches.
|
||||
|
||||
## Critères de succès à terme
|
||||
|
||||
397
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
397
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
@@ -0,0 +1,397 @@
|
||||
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
|
||||
|
||||
## Objet
|
||||
|
||||
`0.1.5` stabilise trois contrats transversaux décidés par la revue d’horizon `0.1.4` avant toute nouvelle adoption réelle : la force de `MUST / SHOULD / MAY`, l’autonomie d’un projet après instanciation ou adoption, et la frontière entre le référentiel normatif PGR et les contenus pratiques candidats à SaseDev Knowledge.
|
||||
|
||||
La release ne doit ni réécrire mécaniquement toutes les recommandations existantes, ni traiter PGR comme un upstream vivant des projets déjà adoptés, ni déplacer du contenu vers Knowledge sans corpus de destination autoritaire.
|
||||
|
||||
## Baseline et preuves d’ouverture
|
||||
|
||||
La baseline autoritaire est l’archive du tag Gitea `v0.1.4`.
|
||||
|
||||
```text
|
||||
archive canonique pgr-v0.1.4.zip
|
||||
archive reçue pgr-v0.1.4(1).zip
|
||||
SHA-256 9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
|
||||
CRC PASS
|
||||
VERSION 0.1.4
|
||||
racine ZIP pgr/
|
||||
fichiers 310
|
||||
répertoires 44
|
||||
symlink 0
|
||||
.git dans l'archive absent — attendu pour une archive de tag
|
||||
```
|
||||
|
||||
La publication post-tag associée a été clôturée `PASS` sous `pgr-0.1.4-publish.001-report.md`. Sa preuve établit le SHA canonique ci-dessus, la publication de la stable `0.1.4` et l’autorisation du handoff vers `prompts/011-V0_1_5_START_PROMPT.md`.
|
||||
|
||||
Le replay indépendant de la baseline avant préparation de `alpha.1` confirme :
|
||||
|
||||
```text
|
||||
tests Python 55/55 PASS
|
||||
audit hygiène texte 309 fichiers PASS
|
||||
audit headers Markdown 282 fichiers PASS
|
||||
audit tables Markdown 11 tables / 282 fichiers PASS
|
||||
audit liens Markdown 357 liens locaux / 282 fichiers PASS
|
||||
JSON 2 fichiers parsés
|
||||
TOML 5 fichiers parsés
|
||||
deltas historiques 103
|
||||
histories historiques 103
|
||||
appariement delta/history exact pour 0.0.1 à 0.1.4
|
||||
```
|
||||
|
||||
La séquence `0.1.4` est conservée telle que publiée :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 FAIL
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
Le `FAIL` de `alpha.2` et son correctif restent des faits historiques ; `0.1.5` ne les réécrit pas.
|
||||
|
||||
## Sources de cadrage
|
||||
|
||||
La release part au minimum de :
|
||||
|
||||
- `RULES.md` ;
|
||||
- `docs/rules/200-GOVERNANCE.md` ;
|
||||
- `docs/rules/210-WORKFLOW.md` ;
|
||||
- `docs/rules/220-SKELETONS.md` ;
|
||||
- `docs/rules/230-ADOPTION.md` ;
|
||||
- `docs/rules/400-VALIDATION.md` ;
|
||||
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` ;
|
||||
- `docs/templates/003-NEW_SESSION_PROMPT.md` ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` ;
|
||||
- `docs/studies/004-V0_1_4_HORIZON_REVIEW.md` ;
|
||||
- `prompts/011-V0_1_5_START_PROMPT.md`.
|
||||
|
||||
Les owners et artefacts adjacents ne sont modifiés que lorsqu’une ambiguïté transversale réelle les concerne.
|
||||
|
||||
## Contrats cibles
|
||||
|
||||
### Force normative
|
||||
|
||||
La release doit rendre non ambigu le contrat suivant :
|
||||
|
||||
```text
|
||||
MUST / MUST NOT obligation ou interdiction normative
|
||||
SHOULD / SHOULD NOT forte recommandation non obligatoire
|
||||
MAY possibilité neutre
|
||||
```
|
||||
|
||||
Un écart à un `SHOULD` ou `SHOULD NOT` :
|
||||
|
||||
- ne constitue pas à lui seul une non-conformité ;
|
||||
- ne fait pas échouer à lui seul une gate ;
|
||||
- n’exige pas automatiquement un `OVERRIDE` ;
|
||||
- peut être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.
|
||||
|
||||
Une contradiction avec un `MUST` réellement applicable reste distincte et continue d’exiger le traitement prévu par l’owner concerné, l’exception ou l’override autorisé.
|
||||
|
||||
### Autonomie après instanciation ou adoption
|
||||
|
||||
Le cycle cible est :
|
||||
|
||||
```text
|
||||
snapshot PGR explicitement choisi
|
||||
↓
|
||||
instanciation / adoption / adaptation
|
||||
↓
|
||||
baseline locale du projet
|
||||
↓
|
||||
autorité locale pour les sessions et releases suivantes
|
||||
```
|
||||
|
||||
Après établissement de la baseline locale, le projet destinataire ne recherche pas automatiquement une version PGR plus récente et ne traite pas PGR comme une dépendance documentaire implicite. Un réalignement futur reste possible uniquement comme opération explicite et bornée, à partir d’un nouveau snapshot PGR choisi et d’une nouvelle comparaison des écarts.
|
||||
|
||||
### Frontière PGR / SaseDev Knowledge
|
||||
|
||||
PGR reste auto-suffisant pour comprendre et appliquer ses exigences.
|
||||
|
||||
PGR conserve notamment les contrats normatifs et de gouvernance, les owners, les skeleton specifications minimales, les templates nécessaires à un contrat réutilisable et les validations directement liées aux règles.
|
||||
|
||||
Les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation sont des candidats à Knowledge. Cette classification n’autorise aucun déplacement automatique pendant `0.1.5` et ne crée aucune dépendance de PGR vers Knowledge.
|
||||
|
||||
## Inventaire transversal `alpha.1`
|
||||
|
||||
L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats d’override, l’autonomie post-adoption et les termes qui confondent spécification normative et recette pratique.
|
||||
|
||||
Sur le corpus normatif/documentaire courant analysé, `29` fichiers contiennent au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences textuelles brutes. Ce volume interdit une conversion mécanique : la majorité de ces recommandations sont légitimes et doivent seulement hériter d’une sémantique globale claire.
|
||||
|
||||
### Ambiguïtés normatives observées en `alpha.1`
|
||||
|
||||
Avant `alpha.2`, `RULES.md` décrivait `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative était « mieux adaptée et justifiée ». Cette formulation pouvait rendre la justification obligatoire et a désigné `RULES.md` comme owner primaire de la clarification.
|
||||
|
||||
Avant `alpha.2`, `RULES.md` exigeait aussi un override pour toute contradiction intentionnelle sans distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
|
||||
|
||||
Avant `alpha.2`, `docs/rules/400-VALIDATION.md` ne précisait pas qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
|
||||
|
||||
Avant `alpha.2`, `docs/rules/230-ADOPTION.md` définissait `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition pouvait pousser à créer un override pour une simple recommandation non suivie.
|
||||
|
||||
`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisaient des formulations d’exception/override pouvant renforcer accidentellement un `SHOULD` ; `alpha.2` les a donc inclus dans la réconciliation ciblée.
|
||||
|
||||
Les cas concrets observés pendant `alpha.1` confirmaient que l’ambiguïté n’était pas théorique :
|
||||
|
||||
- `docs/rules/530-TYPESCRIPT.md` associe une recommandation à une incompatibilité documentée ;
|
||||
- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demandait alors, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
|
||||
- `docs/skeletons/003-WEB_FRONTEND.md` exigeait une justification lorsqu’une nouvelle baseline durable n’adoptait pas la recommandation TypeScript ;
|
||||
- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` imposait une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
|
||||
|
||||
Ces cas ont été retenus pour une correction ciblée en `alpha.2`, sans affaiblir les `MUST` réellement applicables.
|
||||
|
||||
### Ambiguïté de trajectoire observée en `alpha.1`
|
||||
|
||||
Avant `alpha.2`, `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conservait une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` avait déplacé cette adoption en `0.1.6`. `alpha.2` corrige cette référence vivante sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
|
||||
|
||||
### Autonomie — acquis à conserver
|
||||
|
||||
Plusieurs contrats sont déjà compatibles avec la cible :
|
||||
|
||||
- `docs/objectives/001-PROJECT_OBJECTIVES.md` interdit de créer une dépendance vers PGR après instanciation et exclut la maintenance automatique des projets créés ;
|
||||
- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` dit déjà que le projet possède sa copie et qu’une évolution ultérieure de PGR ne le modifie pas automatiquement ;
|
||||
- `docs/rules/220-SKELETONS.md` attribue les fichiers, décisions et règles locales au projet après instanciation ;
|
||||
- `docs/templates/003-NEW_SESSION_PROMPT.md` repart de la baseline stable du projet lui-même et ne reconstruit pas une source absente ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` conclut déjà sur un projet autonome.
|
||||
|
||||
Ces acquis doivent être consolidés plutôt que réécrits en bloc.
|
||||
|
||||
### Autonomie — gaps à fermer
|
||||
|
||||
`RULES.md` interdit seulement la dépendance runtime/build et doit expliciter l’absence d’upstream documentaire PGR implicite.
|
||||
|
||||
`docs/rules/230-ADOPTION.md` doit établir clairement que la baseline locale devient l’autorité des sessions/releases suivantes et qu’un réalignement PGR ultérieur est une opération explicite.
|
||||
|
||||
`docs/rules/220-SKELETONS.md`, `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` et `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` doivent propager ce contrat au point d’instanciation/adoption. Une éventuelle dépendance documentaire externe explicitement choisie par un projet reste sa décision locale ; elle ne transforme pas PGR en upstream implicite.
|
||||
|
||||
`docs/rules/210-WORKFLOW.md` et `docs/templates/003-NEW_SESSION_PROMPT.md` sont, à ce stade, classés `KEEP` sauf contradiction découverte pendant la réconciliation : leur notion de baseline autoritaire est déjà celle du projet courant.
|
||||
|
||||
### Frontière Knowledge — ambiguïtés confirmées
|
||||
|
||||
`docs/objectives/001-PROJECT_OBJECTIVES.md` et `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` qualifient encore un skeleton de « recette Markdown ». Or `0.1.5` réserve précisément les recettes pratiques à la famille de contenus candidats à Knowledge. Le terme doit être remplacé par une formulation de type « spécification Markdown composable » afin de préserver la nature normative/structurelle du skeleton.
|
||||
|
||||
`docs/rules/300-DOCUMENTATION.md` est l’owner naturel pour formaliser la frontière documentaire sans créer un owner Knowledge artificiel. PGR ne doit pas créer une règle ou une collection dédiée uniquement parce que Knowledge existe comme produit séparé.
|
||||
|
||||
## Owners issus de l'inventaire
|
||||
|
||||
L'inventaire `alpha.1` a fixé les owners ci-dessous. Leur modification reste répartie par tranche afin de ne pas mélanger sémantique normative, autonomie et frontière Knowledge.
|
||||
|
||||
```text
|
||||
sémantique primaire
|
||||
RULES.md MODIFY alpha.2
|
||||
docs/rules/230-ADOPTION.md MODIFY alpha.2 puis alpha.3
|
||||
docs/rules/400-VALIDATION.md MODIFY alpha.2
|
||||
|
||||
réconciliation ciblée des effets SHOULD
|
||||
docs/rules/500-LANGUAGES.md MODIFY alpha.2
|
||||
docs/rules/530-TYPESCRIPT.md MODIFY alpha.2
|
||||
docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY alpha.2
|
||||
docs/rules/700-FRAMEWORKS.md MODIFY alpha.2
|
||||
docs/skeletons/003-WEB_FRONTEND.md MODIFY alpha.2
|
||||
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md MODIFY alpha.2
|
||||
|
||||
autonomie
|
||||
RULES.md MODIFY alpha.3
|
||||
docs/rules/220-SKELETONS.md MODIFY alpha.3
|
||||
docs/rules/230-ADOPTION.md MODIFY alpha.3
|
||||
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY alpha.3
|
||||
docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY alpha.3
|
||||
docs/rules/210-WORKFLOW.md KEEP / REVIEW
|
||||
docs/templates/003-NEW_SESSION_PROMPT.md KEEP / REVIEW
|
||||
|
||||
frontière PGR / Knowledge
|
||||
docs/objectives/001-PROJECT_OBJECTIVES.md MODIFY alpha.4
|
||||
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY alpha.4
|
||||
docs/rules/300-DOCUMENTATION.md MODIFY alpha.4
|
||||
```
|
||||
|
||||
Aucun nouveau owner Knowledge n’est prévu par défaut.
|
||||
|
||||
## Progression acquise avant `beta.1`
|
||||
|
||||
La première gate `alpha.1` a acquis les tests et audits principaux mais n'a pas exécuté toutes les assertions contractuelles prévues par son delta. Son history conserve donc le résultat réel `PARTIAL`.
|
||||
|
||||
`alpha.1.fix.1` a été limité à l'acquisition des preuves manquantes : trajectoire ROADMAP, frontière delta/history, assertions du prompt `011`, assertions du présent plan et audits documentaires. Cette récupération est `PASS` et n'a modifié aucun owner normatif.
|
||||
|
||||
La tranche `alpha.2` a ensuite appliqué la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications ont été bornées aux owners et artefacts où l'inventaire avait démontré un renforcement accidentel ou une référence vivante obsolète : `RULES.md`, `230`, `400`, `500`, `530`, `540`, `700`, le skeleton Web `003` et le guide `008`. Sa gate opérateur du `2026-10-01` est `PASS` avec `55/55` tests et les audits documentaires propres.
|
||||
|
||||
Décisions acquises en `alpha.2` :
|
||||
|
||||
- `SHOULD / SHOULD NOT` devient explicitement une forte recommandation non obligatoire ;
|
||||
- un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique ;
|
||||
- un projet MAY documenter la raison d'un écart lorsqu'elle apporte une valeur durable ;
|
||||
- les contradictions avec des obligations `MUST / MUST NOT` restent soumises aux contrats d'exception/override applicables ;
|
||||
- la référence vivante à l'adoption Games est corrigée de `0.1.5` vers `0.1.6` ;
|
||||
- l'autonomie post-adoption est mise en œuvre par `alpha.3` ; la frontière Knowledge reste réservée à `alpha.4`.
|
||||
|
||||
Décisions de mise en œuvre `alpha.3` :
|
||||
|
||||
- après instanciation ou adoption, la baseline locale et ses owners deviennent l'autorité des sessions/releases suivantes ;
|
||||
- PGR ne devient ni dépendance documentaire implicite ni upstream à suivre et aucun mécanisme ne doit rechercher automatiquement « la dernière version de PGR » ;
|
||||
- un réalignement futur exige une opération explicitement décidée et bornée, fondée sur un snapshot PGR précis choisi par le projet ;
|
||||
- ce réalignement compare le snapshot choisi à la baseline locale, reclassifie les écarts utiles et préserve les histories au lieu de mettre à jour silencieusement la gouvernance ;
|
||||
- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : leur contrat de reprise depuis la baseline autoritaire du projet est déjà compatible ;
|
||||
- la frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`.
|
||||
|
||||
La gate opérateur de `alpha.3` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres et le scope Git attendu. Le contrat d'autonomie locale est donc acquis avant ouverture de `alpha.4`.
|
||||
|
||||
Décisions de mise en œuvre `alpha.4` :
|
||||
|
||||
- remplacer les formulations « recette Markdown » des skeletons par « spécification Markdown composable » afin de ne pas confondre contrat structurel PGR et recette pratique ;
|
||||
- formaliser dans `300-DOCUMENTATION.md` une frontière documentaire où PGR possède les éléments nécessaires à ses contrats normatifs et où les howtos détaillés, recettes, snippets, exemples, dépannage, comparatifs et variantes MAY vivre dans une base de connaissances séparée ;
|
||||
- mentionner SaseDev Knowledge uniquement comme destination pratique possible, jamais comme owner normatif ni dépendance requise ;
|
||||
- imposer l'auto-suffisance de PGR : aucun howto/snippet externe ne peut être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR ;
|
||||
- conserver toute migration physique hors scope de `0.1.5` tant qu'une destination Knowledge autoritaire n'est pas explicitement fournie et vérifiée ;
|
||||
- ne créer aucun nouvel owner Knowledge et ne modifier aucun history antérieur.
|
||||
|
||||
La gate opérateur de `alpha.4` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres, les owners hors scope inchangés et le scope Git attendu. La frontière PGR / Knowledge est donc acquise avant ouverture de `beta.1`.
|
||||
|
||||
## Réconciliation transversale préparée en `beta.1`
|
||||
|
||||
Le rescan préparatoire de la baseline post-`alpha.4` n'a démontré aucun nouveau défaut normatif exigeant une modification d'owner.
|
||||
|
||||
Les formulations `SHOULD / SHOULD NOT` des owners vivants ont été relues avec attention lorsqu'un `MUST`, une justification ou une contrainte conditionnelle apparaissait dans le même contexte. Les cas conservés portent des responsabilités distinctes et ne transforment pas le simple écart à la recommandation en non-conformité : outputs/caches générés à ignorer lorsqu'ils restent dans l'arbre, ouverture réseau/CORS à borner, identité Android à rendre explicite, dépendance Sass interne à garder visible/révisable et surface de sécurité Tauri à décider explicitement.
|
||||
|
||||
La réconciliation confirme également :
|
||||
|
||||
- `RULES.md`, `230-ADOPTION.md` et `400-VALIDATION.md` portent une sémantique cohérente : un écart à `SHOULD / SHOULD NOT` ne crée à lui seul ni `FAIL`, ni `OVERRIDE`, ni justification obligatoire ;
|
||||
- `220-SKELETONS.md`, `230-ADOPTION.md`, `001-PROJECT_GOVERNANCE_FOUNDATION.md` et `007-EXISTING_PROJECT_ADOPTION.md` conservent la baseline locale comme autorité et le réalignement PGR comme opération explicite sur snapshot choisi ;
|
||||
- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : aucune recherche automatique de version PGR plus récente n'y est introduite ;
|
||||
- `001-PROJECT_OBJECTIVES.md`, `002-GOVERNANCE_ARCHITECTURE.md` et `300-DOCUMENTATION.md` maintiennent PGR auto-suffisant et Knowledge strictement complémentaire ;
|
||||
- la référence vivante Games dans `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` pointe bien vers `0.1.6` ; les anciennes mentions `0.1.5` conservées dans des études/index historiques restent des descriptions de l'horizon de leur époque et ne sont pas réécrites ;
|
||||
- les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` restent réservés et aucun `0.1.9` n'est créé.
|
||||
|
||||
Décision `beta.1` : **KEEP des owners normatifs acquis**. La tranche documente et valide la réconciliation ; elle n'ajoute aucun owner, ne modifie aucune règle normative et ne commence aucun scope futur.
|
||||
|
||||
La gate opérateur de `beta.1` du `2026-10-01` est `PASS` avec `55/55` tests, l'audit d'hygiène texte propre sur `321` fichiers, les audits Markdown propres et le scope Git attendu. La phase de réconciliation est donc acquise avant ouverture de `rc.1`.
|
||||
|
||||
## Freeze et revue d’horizon préparés en `rc.1`
|
||||
|
||||
`rc.1` gèle les owners normatifs acquis : aucune règle, skeleton, template ou validation stabilisés pendant `alpha.2` à `alpha.4` n'est réouvert sans défaut démontré.
|
||||
|
||||
La revue d'horizon limitée matérialisée dans `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` conclut qu'aucun nouveau prérequis transversal ne doit précéder l'adoption Games. La trajectoire reste :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
0.1.9 NOT RESERVED
|
||||
```
|
||||
|
||||
Le prompt `012-V0_1_6_START_PROMPT.md` prépare donc une reprise `0.1.6-alpha.1` à partir d'une future stable PGR `v0.1.5` réellement publiée et d'une archive Games récente explicitement autoritaire. Il impose un intake/cartographie avant toute migration et conserve le contrat d'autonomie locale après adoption.
|
||||
|
||||
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`.
|
||||
|
||||
## 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
|
||||
|
||||
- vérifier la baseline stable `0.1.4` et sa chaîne delta/history ;
|
||||
- relire le handoff `011` et la revue d’horizon `004` ;
|
||||
- inventorier les ambiguïtés normatives, d’autonomie et de frontière Knowledge ;
|
||||
- proposer les owners exacts ;
|
||||
- ne modifier aucune règle normative.
|
||||
|
||||
### `alpha.2` — sémantique normative et conséquences de gate/adoption
|
||||
|
||||
- stabiliser `MUST / SHOULD / MAY` dans l’owner primaire ;
|
||||
- aligner `230-ADOPTION.md` et `400-VALIDATION.md` ;
|
||||
- corriger les cas concrets où une recommandation est transformée en justification/override obligatoire ;
|
||||
- corriger la référence vivante obsolète à l’adoption Games `0.1.5` ;
|
||||
- conserver les obligations réelles et les histories inchangées.
|
||||
|
||||
### `alpha.3` — autonomie locale et réalignement volontaire
|
||||
|
||||
- expliciter la baseline locale comme autorité après instanciation/adoption ;
|
||||
- interdire la recherche automatique de « la dernière PGR » dans le contrat d’adoption ;
|
||||
- définir le réalignement futur comme scope explicite fondé sur un snapshot choisi ;
|
||||
- propager le contrat aux skeleton/patterns concernés sans réécriture des documents déjà corrects.
|
||||
|
||||
### `alpha.4` — frontière PGR / SaseDev Knowledge
|
||||
|
||||
- clarifier la taxonomie normative/pratique ;
|
||||
- remplacer les formulations « recette Markdown » qui brouillent la nature des skeleton specifications ;
|
||||
- maintenir PGR auto-suffisant ;
|
||||
- ne déplacer aucun contenu vers Knowledge sans destination autoritaire fournie.
|
||||
|
||||
### `beta.1` — réconciliation transversale
|
||||
|
||||
- rescanner toutes les formulations `SHOULD / SHOULD NOT` pour détecter les renforcements accidentels restants ;
|
||||
- vérifier les références à l’autonomie, aux snapshots et aux overrides ;
|
||||
- rechercher les références vivantes devenues obsolètes après la revue d’horizon ;
|
||||
- vérifier que Games `0.1.6`, KSP `0.1.7` et les audits Rust `0.1.8` n’ont pas été commencés ;
|
||||
- exécuter les validations PGR complètes et proportionnées.
|
||||
|
||||
### `rc.1` — freeze et handoff
|
||||
|
||||
- figer les contrats stabilisés ;
|
||||
- mettre à jour la présentation stable/candidate et la roadmap selon l’état réellement atteint ;
|
||||
- préparer le prompt de reprise suivant uniquement si la trajectoire vers `0.1.6` reste valide ;
|
||||
- effectuer une revue d’horizon limitée aux dépendances réellement révélées par `0.1.5`.
|
||||
|
||||
### `rel.1` — promotion stable
|
||||
|
||||
- promouvoir la RC validée sans nouveau scope fonctionnel ;
|
||||
- produire le history réel de clôture ;
|
||||
- préparer la publication/tag stable puis sa vérification post-tag selon le workflow PGR.
|
||||
|
||||
## Hors scope maintenu
|
||||
|
||||
`0.1.5` ne commence pas :
|
||||
|
||||
- l’adoption réelle de `sasedev-games`, réservée à `0.1.6` ;
|
||||
- l’adoption réelle de `khadhroony-solana-project`, réservée à `0.1.7` ;
|
||||
- les audits Rust/Clippy read-only, réservés à `0.1.8` ;
|
||||
- une réouverture du domaine Tauri sans défaut transversal démontré ;
|
||||
- une migration physique vers SaseDev Knowledge ;
|
||||
- une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
|
||||
|
||||
## Gate de planification `alpha.1` — historique
|
||||
|
||||
`alpha.1` était prête à validation opérateur lorsque :
|
||||
|
||||
- la baseline `0.1.4` a été rejouée proprement ;
|
||||
- l’historique `0.1.4` reste intact, y compris `alpha.2 FAIL` puis `alpha.2.fix.1 PASS` ;
|
||||
- les ambiguïtés ci-dessus sont traçables à des owners existants ;
|
||||
- aucune règle normative n’est modifiée par la tranche ;
|
||||
- le plan conserve une séparation explicite entre sémantique, autonomie et frontière Knowledge ;
|
||||
- les scopes `0.1.6`, `0.1.7` et `0.1.8` restent réservés.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/220-SKELETONS.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Skeleton specification rules
|
||||
|
||||
@@ -23,7 +23,9 @@ Un skeleton MUST NOT devenir :
|
||||
- un moyen de figer une architecture au-delà du scope qu'il déclare ;
|
||||
- un catalogue de technologies ou de fichiers créés par anticipation.
|
||||
|
||||
Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet.
|
||||
Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Cette baseline locale devient l'autorité de ses sessions et releases suivantes. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet et le projet MUST NOT rechercher automatiquement une version PGR plus récente.
|
||||
|
||||
Un réalignement futur MAY être décidé explicitement. Il doit alors partir d'un snapshot PGR précis choisi par le projet, comparer ce snapshot à la baseline locale et appliquer uniquement les écarts explicitement retenus. Ce réalignement est une nouvelle opération bornée ; il ne transforme pas PGR en upstream documentaire permanent.
|
||||
|
||||
## Applicabilité
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/230-ADOPTION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Existing project adoption rules
|
||||
|
||||
@@ -17,7 +17,7 @@ PGR s’adapte au besoin réel du projet existant ; il ne cherche pas à effacer
|
||||
|
||||
Une adoption MUST partir d’une baseline autoritaire réellement observée : commit, tag, archive de release ou autre état explicitement accepté par le projet. Le travail d’adoption MUST distinguer ce qui existe déjà de ce que PGR propose d’ajouter ou de modifier.
|
||||
|
||||
Une migration réussie produit un projet autonome gouverné localement. Le projet destinataire ne devient pas dépendant runtime ou build du dépôt PGR.
|
||||
Une migration réussie produit un projet autonome gouverné localement. Une fois la baseline locale établie, elle devient l'autorité des sessions et releases suivantes du projet. Le projet destinataire ne devient pas dépendant runtime, build ou documentaire implicite du dépôt PGR et MUST NOT rechercher automatiquement « la dernière version de PGR ».
|
||||
|
||||
## Audit initial de la baseline
|
||||
|
||||
@@ -50,6 +50,8 @@ OVERRIDE
|
||||
DEFER
|
||||
```
|
||||
|
||||
Ces classifications n'augmentent pas la force normative d'une règle. En particulier, choisir une solution différente d'un `SHOULD` / `SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire ; le projet MAY conserver ce choix comme décision locale et documenter sa raison lorsque cette trace apporte une valeur durable.
|
||||
|
||||
### ADOPT
|
||||
|
||||
`ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
|
||||
@@ -64,9 +66,9 @@ Cette classification ne crée pas une exception : elle reconnaît qu’un choix
|
||||
|
||||
### OVERRIDE
|
||||
|
||||
`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée dans un scope local.
|
||||
`OVERRIDE` signifie qu'une obligation PGR réellement applicable, ou un contrat localement rendu obligatoire, est volontairement remplacé ou raffiné dans un scope local.
|
||||
|
||||
L’override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue.
|
||||
L'override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue. Un simple écart à une recommandation `SHOULD` / `SHOULD NOT` MUST NOT exiger un override uniquement parce que la recommandation n'est pas suivie.
|
||||
|
||||
### DEFER
|
||||
|
||||
@@ -96,6 +98,22 @@ Les conventions nouvelles s’appliquent à partir du point d’adoption explici
|
||||
|
||||
Une adoption MAY documenter des écarts hérités comme dette, exception temporaire ou contexte historique sans modifier les snapshots qui les ont produits.
|
||||
|
||||
## Autorité locale et réalignement futur
|
||||
|
||||
Après clôture du scope d'adoption, les règles, plans, décisions, validations et historiques locaux gouvernent les travaux suivants. Les sessions et releases ultérieures MUST partir de cette baseline locale et non d'une recherche automatique d'une version PGR plus récente.
|
||||
|
||||
PGR n'est pas un upstream documentaire implicite. Une référence, URL ou archive PGR utilisée pendant l'adoption reste une source de comparaison de cette opération ; elle ne crée pas un abonnement aux évolutions futures du référentiel. Une dépendance documentaire externe MAY exister uniquement si le projet la choisit et la possède explicitement comme contrat local.
|
||||
|
||||
Un réalignement futur avec PGR MAY être engagé lorsqu'il apporte une valeur réelle. Cette opération MUST être explicite et bornée. Elle doit au minimum :
|
||||
|
||||
1. identifier le snapshot PGR choisi, par exemple version, tag, commit ou archive ;
|
||||
2. repartir de la baseline locale autoritaire du projet ;
|
||||
3. comparer les owners applicables et classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
4. définir le scope et les validations de la migration ;
|
||||
5. préserver les histories, tags et décisions historiques au lieu de les réécrire pour simuler une conformité continue.
|
||||
|
||||
Le réalignement ne doit pas être présenté comme une mise à jour automatique. Entre deux opérations explicitement décidées, la gouvernance locale reste autonome et suffisante pour reprendre le projet.
|
||||
|
||||
## Relation avec les skeletons et templates
|
||||
|
||||
Un skeleton PGR MAY servir de checklist de comparaison pour un projet existant. Il ne doit pas être appliqué comme si le dépôt était vide.
|
||||
@@ -116,10 +134,10 @@ Une adoption n’est terminée que lorsque les décisions de son scope sont clas
|
||||
|
||||
Une adoption PGR réussie laisse :
|
||||
|
||||
- un projet autonome ;
|
||||
- un projet autonome dont la baseline locale gouverne les sessions et releases suivantes ;
|
||||
- uniquement les owners PGR réellement applicables ;
|
||||
- les choix locaux légitimes préservés ;
|
||||
- les overrides explicites ;
|
||||
- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;
|
||||
- les domaines différés clairement identifiés ;
|
||||
- un historique non falsifié ;
|
||||
- une validation proportionnée au changement réellement effectué.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/300-DOCUMENTATION.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Documentation rules
|
||||
|
||||
@@ -145,6 +145,27 @@ Un répertoire générique tel que `misc/` SHOULD NOT devenir la destination par
|
||||
|
||||
Une technologie ou un projet MAY introduire des familles supplémentaires lorsqu'elles représentent une responsabilité documentaire stable.
|
||||
|
||||
## Frontière normative et pratique
|
||||
|
||||
La documentation gouvernée par PGR distingue les informations nécessaires au contrat PGR des contenus pratiques complémentaires.
|
||||
|
||||
Restent possédés par PGR lorsqu'ils sont nécessaires à la compréhension ou à l'application du référentiel :
|
||||
|
||||
- règles et contrats de gouvernance ;
|
||||
- objectifs et architecture qui définissent le sens durable du référentiel ;
|
||||
- owners normatifs ;
|
||||
- skeleton specifications minimales ;
|
||||
- templates nécessaires à un contrat réutilisable ;
|
||||
- matrices, validations et preuves directement liées aux règles.
|
||||
|
||||
Les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation MAY être maintenus dans une base de connaissances séparée lorsqu'une destination réelle et autoritaire existe. SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR.
|
||||
|
||||
PGR MUST rester auto-suffisant : une règle PGR MUST être compréhensible et applicable sans consulter un howto ou snippet externe. Un contenu externe MAY fournir des exemples ou une aide opérationnelle, mais MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR.
|
||||
|
||||
Classifier un contenu comme pratique ne crée pas une obligation de déplacement. Une migration physique vers une base de connaissances externe MUST être une opération explicitement décidée, fondée sur une destination autoritaire fournie et vérifiée. Tant que cette condition n'est pas remplie, le contenu existant MAY rester dans PGR s'il conserve une utilité réelle.
|
||||
|
||||
Cette séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou vers un autre dépôt documentaire externe.
|
||||
|
||||
## Idées, études et décisions
|
||||
|
||||
Une idée est une possibilité non engagée. Elle ne doit pas être présentée comme une décision ou une promesse de roadmap.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/400-VALIDATION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Validation rules
|
||||
|
||||
@@ -27,6 +27,12 @@ Une preuve déjà acquise MAY être réutilisée tant qu'aucun changement pertin
|
||||
|
||||
Les gates de `beta`, `rc` et promotion stable MAY élargir volontairement la validation pour démontrer l'intégration ou la cohérence de release.
|
||||
|
||||
## Force normative et résultat des gates
|
||||
|
||||
Une gate MUST distinguer une obligation `MUST / MUST NOT` d'une recommandation `SHOULD / SHOULD NOT`. Un écart à un `SHOULD` ou `SHOULD NOT` PGR ne constitue pas à lui seul une preuve en échec et MUST NOT faire passer une tranche en `FAIL`.
|
||||
|
||||
Une gate MAY signaler un écart à une recommandation comme observation, diagnostic ou point de revue. Si un projet décide de rendre cette recommandation obligatoire dans un scope local, il doit matérialiser ce contrat local explicitement ; la gate évalue alors ce contrat local, pas le `SHOULD` PGR d'origine.
|
||||
|
||||
## Matrice de validation
|
||||
|
||||
Un projet suffisamment structuré SHOULD posséder une matrice de validation canonique, par défaut sous :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/500-LANGUAGES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Règles de profils langage et écosystème
|
||||
|
||||
@@ -31,7 +31,7 @@ Les profils de cette famille héritent des règles générales PGR et ne doivent
|
||||
|
||||
Une règle générale comme l'interdiction de versionner des secrets reste applicable sans être répétée dans chaque profil langage.
|
||||
|
||||
Lorsqu'un langage ou un build tool impose une exception réelle à une règle générale, le profil spécifique doit déclarer l'override et sa justification.
|
||||
Lorsqu'un langage ou un build tool impose une contradiction réelle avec un `MUST / MUST NOT` général applicable, le profil spécifique MUST déclarer l'override ou l'exception et sa justification. Un choix différent d'un `SHOULD / SHOULD NOT` général ne nécessite pas, à lui seul, un override.
|
||||
|
||||
## Langage et build tool
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/530-TYPESCRIPT.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Profil TypeScript
|
||||
|
||||
@@ -15,7 +15,7 @@ Le profil s'applique lorsqu'une partie du source contrôlé est écrite en TypeS
|
||||
|
||||
Pour un frontend que l'organisation contrôle, TypeScript **SHOULD** être préféré à du JavaScript non typé dès que le frontend porte une logique durable non triviale.
|
||||
|
||||
Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée.
|
||||
Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée. Choisir JavaScript ne constitue donc pas à lui seul une non-conformité, n'exige pas automatiquement un `OVERRIDE` et ne crée pas une obligation de justification ; la décision MAY être documentée lorsqu'elle apporte une valeur durable.
|
||||
|
||||
La justification de la recommandation est fonctionnelle : TypeScript ajoute une vérification statique avant exécution et permet de détecter une partie des incohérences de types pendant la validation plutôt qu'au runtime.
|
||||
|
||||
@@ -61,7 +61,7 @@ noEmit = true
|
||||
|
||||
`strict` exprime la volonté d'utiliser le contrôle de types renforcé de TypeScript. `noEmit` sépare le type-check de la production des artefacts JavaScript lorsque cette production appartient à un bundler ou à un autre outil.
|
||||
|
||||
Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants sauf incompatibilité documentée :
|
||||
Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants lorsqu'ils sont pertinents pour le package :
|
||||
|
||||
```text
|
||||
noUnusedLocals = true
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Profil écosystème de packages JavaScript
|
||||
|
||||
@@ -67,7 +67,7 @@ Un package **SHOULD NOT** conserver simultanément plusieurs lockfiles concurren
|
||||
|
||||
Lorsqu'un lockfile est versionné, la CI **SHOULD** utiliser le mode de résolution gelé, immutable ou clean-install fourni par le package manager sélectionné. Le nom exact de cette commande reste local à l'outil ; PGR MUST NOT transformer `npm ci` en commande universelle.
|
||||
|
||||
L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.5`, chaque package concerné devra soit `ADOPT` cette recommandation, soit documenter un `OVERRIDE` si une autre politique reste préférable.
|
||||
L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.6`, chaque package concerné devra décider sa politique de lockfile selon son rôle et ses contraintes. Versionner le lockfile reste une recommandation `SHOULD` pour les applications privées, frontends déployables et outils livrés ; conserver une autre politique ne requiert pas à lui seul un `OVERRIDE`, même si la décision locale MAY être documentée lorsqu'elle apporte une valeur durable.
|
||||
|
||||
## Validation
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/700-FRAMEWORKS.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Règles de profils framework
|
||||
|
||||
@@ -45,7 +45,7 @@ GENERAL
|
||||
+ Tauri
|
||||
```
|
||||
|
||||
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
|
||||
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope avec leur force normative propre. Un framework MUST NOT contredire silencieusement un `MUST / MUST NOT` hérité ; une telle contradiction exige l'override ou l'exception applicable. Un framework MAY choisir différemment d'un `SHOULD / SHOULD NOT` sans que cet écart constitue à lui seul un override ou une non-conformité.
|
||||
|
||||
Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Skeleton — Project governance foundation
|
||||
|
||||
@@ -70,7 +70,9 @@ Ce document doit au minimum :
|
||||
- expliquer la priorité ou la spécialisation locale lorsqu'une adaptation existe ;
|
||||
- renvoyer vers les documents détaillés au lieu de recopier leur contenu sans nécessité.
|
||||
|
||||
Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable.
|
||||
Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi et possédé par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable et ne crée pas un upstream documentaire implicite.
|
||||
|
||||
À l'issue de l'instanciation, la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes. Le projet MUST NOT rechercher automatiquement « la dernière version de PGR ». Un réalignement ultérieur MAY être entrepris uniquement comme opération explicite à partir d'un snapshot PGR précis choisi puis comparé à cette baseline locale.
|
||||
|
||||
### Version
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/skeletons/003-WEB_FRONTEND.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Skeleton — Web frontend
|
||||
|
||||
@@ -65,7 +65,7 @@ Le nom `frontend/` est une convention possible, pas un chemin imposé par ce ske
|
||||
Résoudre explicitement au minimum :
|
||||
|
||||
1. la racine et le scope exacts du frontend ;
|
||||
2. TypeScript ou JavaScript, avec justification si une nouvelle baseline durable n'adopte pas la recommandation TypeScript ;
|
||||
2. TypeScript ou JavaScript ; pour une nouvelle baseline durable, considérer explicitement la recommandation TypeScript sans transformer un choix JavaScript en obligation de justification ou en `OVERRIDE` ;
|
||||
3. le package manager réel et la politique de lockfile adaptée au rôle du package ;
|
||||
4. les versions réelles de TypeScript et des dépendances, ainsi que les déclarations `@types/*` réellement nécessaires ;
|
||||
5. Vite ou un build tool alternatif, avec ses chemins `root`, cache, outputs, `base`, ports, plugins et assets lorsqu'ils s'appliquent ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/000-README.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Index des études PGR
|
||||
|
||||
@@ -13,3 +13,4 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti
|
||||
- [`002-TAURI_SKELETON_DECISION.md`](002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER` du skeleton Tauri, complétée en `0.1.1-beta.1` par la preuve que ses cinq prérequis Web disposent désormais d'owners PGR, sans lever le report avant `0.1.4`.
|
||||
- [`003-V0_1_0_HORIZON_REVIEW.md`](003-V0_1_0_HORIZON_REVIEW.md) — revue d'horizon `0.1.0-beta.1` engageant les prochaines releases `0.1.x` suffisamment décidées et conservant les autres axes sans numéro.
|
||||
- [`004-V0_1_4_HORIZON_REVIEW.md`](004-V0_1_4_HORIZON_REVIEW.md) — revue de fermeture `0.1.4` clarifiant le besoin d’une release `0.1.5` dédiée à la sémantique normative, à l’autonomie des projets et à la frontière PGR / SaseDev Knowledge avant les adoptions Games/KSP.
|
||||
- [`005-V0_1_5_HORIZON_REVIEW.md`](005-V0_1_5_HORIZON_REVIEW.md) — revue de fermeture `0.1.5` confirmant qu’aucun nouveau prérequis transversal ne précède l’adoption réelle de `sasedev-games` en `0.1.6`, puis KSP `0.1.7` et les audits Rust/Clippy `0.1.8`.
|
||||
|
||||
105
docs/studies/005-V0_1_5_HORIZON_REVIEW.md
Normal file
105
docs/studies/005-V0_1_5_HORIZON_REVIEW.md
Normal file
@@ -0,0 +1,105 @@
|
||||
<!-- file: docs/studies/005-V0_1_5_HORIZON_REVIEW.md -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Revue d’horizon 0.1.5 — adoption Games après stabilisation des contrats transversaux
|
||||
|
||||
## Objet
|
||||
|
||||
Cette étude clôt la revue d’horizon limitée exigée par le plan `0.1.5`. Elle vérifie si la stabilisation de la sémantique normative, de l’autonomie locale et de la frontière PGR / SaseDev Knowledge révèle un nouveau prérequis avant l’adoption réelle de `sasedev-games`.
|
||||
|
||||
La revue ne cherche pas à prolonger artificiellement la roadmap. Elle réévalue uniquement les dépendances déjà engagées et les faits démontrés pendant `0.1.5`.
|
||||
|
||||
## Contrats acquis en 0.1.5
|
||||
|
||||
La release candidate s’appuie sur trois contrats désormais réconciliés :
|
||||
|
||||
```text
|
||||
SHOULD / SHOULD NOT forte recommandation non obligatoire
|
||||
baseline locale autorité des sessions/releases suivantes
|
||||
PGR / Knowledge PGR normatif auto-suffisant, Knowledge pratique complémentaire
|
||||
```
|
||||
|
||||
La gate `beta.1` confirme qu’aucun nouveau renforcement accidentel de `SHOULD`, aucune dépendance implicite à une version PGR plus récente et aucune dépendance normative vers SaseDev Knowledge ne restent démontrés dans les owners relus.
|
||||
|
||||
## Vérification du prochain prérequis réel
|
||||
|
||||
La trajectoire précédente réserve :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
```
|
||||
|
||||
`0.1.5` n’a révélé aucun owner transversal supplémentaire qui devrait obligatoirement précéder l’adoption Games.
|
||||
|
||||
Les contrats maintenant disponibles suffisent pour engager une adoption proportionnée :
|
||||
|
||||
- classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
- distinction explicite entre obligations `MUST` et recommandations `SHOULD` ;
|
||||
- baseline locale autonome après adoption ;
|
||||
- réalignement futur uniquement explicite et fondé sur un snapshot PGR choisi ;
|
||||
- validation proportionnée au scope réellement applicable ;
|
||||
- absence de dépendance normative vers Knowledge.
|
||||
|
||||
Décision : **conserver `0.1.6` comme prochaine release et y effectuer l’adoption réelle de `sasedev-games`**.
|
||||
|
||||
## Corpus requis pour 0.1.6
|
||||
|
||||
La future session `0.1.6` doit disposer de deux baselines autoritaires distinctes :
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
## Méthode attendue pour l’adoption Games
|
||||
|
||||
`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. La classification canonique est `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` :
|
||||
|
||||
```text
|
||||
ADOPT intégré dans la baseline locale Games
|
||||
KEEP-LOCAL décision Games conservée comme autorité locale
|
||||
OVERRIDE contradiction réelle avec un MUST PGR applicable, documentée et bornée
|
||||
DEFER applicable potentiellement mais non justifié dans le scope courant
|
||||
N/A non applicable au corpus Games observé
|
||||
```
|
||||
|
||||
Un simple écart à un `SHOULD / SHOULD NOT` ne constitue pas à lui seul un `OVERRIDE`.
|
||||
|
||||
L’adoption doit préserver les décisions produit et architectures locales qui ne relèvent pas de PGR. Les anciens POCs, technologies historiques ou artefacts expérimentaux ne doivent pas devenir des surfaces applicables uniquement parce qu’ils existent dans l’historique : leur applicabilité doit être démontrée par la baseline Games fournie.
|
||||
|
||||
## Autorité après adoption
|
||||
|
||||
`0.1.6` doit exercer le contrat stabilisé en `0.1.5` : une fois l’adoption matérialisée, les règles, plans, architecture, histories et autres owners locaux de Games deviennent l’autorité des sessions/releases suivantes du projet.
|
||||
|
||||
PGR ne devient pas un upstream documentaire à suivre. Un futur réalignement Games/PGR doit rester une opération explicitement décidée à partir d’un snapshot PGR précis.
|
||||
|
||||
## Trajectoire conservée
|
||||
|
||||
Aucune dépendance nouvelle ne justifie un changement d’ordre :
|
||||
|
||||
```text
|
||||
0.1.5 sémantique normative + autonomie + frontière PGR/Knowledge
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
```
|
||||
|
||||
`0.1.7` reste séparée afin que l’adoption KSP soit instruite contre son propre corpus et son propre scope applicable.
|
||||
|
||||
`0.1.8` reste postérieure aux deux adoptions : les audits Rust/Clippy statiques doivent être dérivés de besoins effectivement éprouvés et ne pas être inventés avant les retours d’adoption.
|
||||
|
||||
Aucun `0.1.9` n’est réservé par cette revue.
|
||||
|
||||
## Hors scope de la présente RC
|
||||
|
||||
Cette étude ne commence pas l’adoption Games et ne modifie aucune règle Games.
|
||||
|
||||
Elle ne commence ni l’adoption KSP, ni les audits Rust/Clippy `0.1.8`, ni une migration de contenu vers SaseDev Knowledge.
|
||||
|
||||
Elle ne transforme pas PGR en dépendance des projets adoptés et ne crée aucun mécanisme automatique de suivi de la dernière version PGR.
|
||||
21
docs/templates/007-EXISTING_PROJECT_ADOPTION.md
vendored
21
docs/templates/007-EXISTING_PROJECT_ADOPTION.md
vendored
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/templates/007-EXISTING_PROJECT_ADOPTION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Pattern — adoption PGR d’un projet existant
|
||||
|
||||
@@ -14,13 +14,14 @@ Il peut être instancié comme étude, plan, tableau de décision ou section d
|
||||
Consigner uniquement ce qui est réellement établi :
|
||||
|
||||
```text
|
||||
repository / archive : <source>
|
||||
repository / archive : <source locale autoritaire>
|
||||
commit / tag : <si connu>
|
||||
version : <si applicable>
|
||||
snapshot PGR choisi : <version / tag / commit / archive de comparaison>
|
||||
validation connue : <preuves déjà acquises et encore pertinentes>
|
||||
```
|
||||
|
||||
Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR.
|
||||
Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR. Le snapshot PGR est une entrée de comparaison explicitement choisie pour cette opération ; il n'est pas un upstream que le projet doit suivre ensuite.
|
||||
|
||||
## Inventaire utile
|
||||
|
||||
@@ -74,6 +75,20 @@ Exemples :
|
||||
- dette héritée documentée mais non réécrite rétroactivement.
|
||||
```
|
||||
|
||||
|
||||
## Autorité après adoption
|
||||
|
||||
À la clôture du scope, consigner explicitement que la baseline locale obtenue devient l'autorité des sessions et releases suivantes. Une forme courte suffit :
|
||||
|
||||
```text
|
||||
baseline locale autoritaire : <version / commit / état accepté>
|
||||
réalignement PGR automatique : non
|
||||
```
|
||||
|
||||
Les reprises ultérieures partent des règles, plans, architecture et histories du projet. Elles ne recherchent pas automatiquement « la dernière version de PGR ».
|
||||
|
||||
Si un réalignement futur est souhaité, ouvrir une nouvelle opération bornée : choisir un snapshot PGR précis, comparer ses owners applicables à la baseline locale, classifier les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis valider seulement le scope retenu. Les snapshots historiques locaux restent inchangés.
|
||||
|
||||
## Validation de sortie
|
||||
|
||||
L’adoption du scope est prête lorsque :
|
||||
|
||||
4
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
vendored
4
docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
vendored
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md -->
|
||||
<!-- version: 2 -->
|
||||
<!-- version: 3 -->
|
||||
|
||||
# Templates de package Web TypeScript
|
||||
|
||||
@@ -135,7 +135,7 @@ Ces lignes sont des exemples, pas une sélection de package manager par PGR.
|
||||
|
||||
Pour une application privée/deployable issue de ce template, le lockfile du package manager sélectionné SHOULD normalement être versionné.
|
||||
|
||||
Si le projet conserve volontairement une autre politique, l'écart doit être traité comme décision locale ou `OVERRIDE` lors d'une adoption PGR, avec justification proportionnée.
|
||||
Si le projet conserve volontairement une autre politique, l'écart reste une décision locale. Ne pas suivre ce `SHOULD` n'exige pas à lui seul un `OVERRIDE` ni une justification ; documenter la raison reste utile lorsqu'elle apporte une valeur durable de maintenance, reproductibilité ou reprise.
|
||||
|
||||
PGR MUST NOT conserver plusieurs lockfiles concurrents uniquement pour rendre le template compatible avec plusieurs package managers.
|
||||
|
||||
|
||||
97
history/0.1.5/alpha.1.fix.1.md
Normal file
97
history/0.1.5/alpha.1.fix.1.md
Normal file
@@ -0,0 +1,97 @@
|
||||
<!-- file: history/0.1.5/alpha.1.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.1.fix.1 — preuves de cadrage complétées
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.1.fix.1` exécutée le `2026-09-30` est propre. Les preuves requises mais absentes du premier transcript `alpha.1` ont été acquises sans modifier le contenu normatif ; le résultat `PARTIAL` de `alpha.1` reste conservé comme fait historique et `alpha.2` peut maintenant commencer.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-alpha.1` et son history `PARTIAL` ont été committés puis publiés avant application du fix :
|
||||
|
||||
```text
|
||||
commit alpha.1 90ca422
|
||||
push c41b69b..90ca422 master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate du fix est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.1.fix.1
|
||||
```
|
||||
|
||||
`history/0.1.5/alpha.1.md` est présent avec le statut `PARTIAL`, tandis que `history/0.1.5/alpha.1.fix.1.md` était absent pendant la gate.
|
||||
|
||||
## Trajectoire et frontière historique
|
||||
|
||||
Les contrôles ROADMAP ont confirmé :
|
||||
|
||||
```text
|
||||
0.1.4 terminé
|
||||
0.1.5 engagé — sémantique normative + autonomie + frontière PGR/Knowledge
|
||||
0.1.6 engagé — adoption sasedev-games
|
||||
0.1.7 engagé — adoption khadhroony-solana-project
|
||||
0.1.8 engagé — audits Rust/Clippy read-only
|
||||
0.1.9 non réservé
|
||||
```
|
||||
|
||||
Le contrôle d'appariement a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 alpha.1.fix.1 history boundary: clean (104 closed prior pairs, current fix pending)
|
||||
```
|
||||
|
||||
Il confirme l'appariement exact des releases stables `0.0.1` à `0.1.4`, puis `alpha.1.md` présent à la fois sous `deltas/0.1.5` et `history/0.1.5`, avec `alpha.1.fix.1.md` encore en attente de son history pendant la gate.
|
||||
|
||||
## Contrat du prompt et du plan
|
||||
|
||||
Les assertions ciblées sur `prompts/011-V0_1_5_START_PROMPT.md` ont confirmé :
|
||||
|
||||
- `SHOULD / SHOULD NOT` comme forte recommandation non obligatoire ;
|
||||
- absence de recherche automatique de « la dernière version de PGR » après établissement d'une baseline locale ;
|
||||
- adoption Games réservée à `0.1.6` ;
|
||||
- adoption KSP réservée à `0.1.7` ;
|
||||
- audits Rust/Clippy réservés à `0.1.8`.
|
||||
|
||||
Les assertions ciblées sur `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` ont confirmé :
|
||||
|
||||
- `29` fichiers contenant `SHOULD / SHOULD NOT` pour `242` occurrences textuelles brutes ;
|
||||
- `alpha.2` réservé à la sémantique normative et aux conséquences de gate/adoption ;
|
||||
- `alpha.3` réservé à l'autonomie locale et au réalignement volontaire ;
|
||||
- `alpha.4` réservé à la frontière PGR / SaseDev Knowledge.
|
||||
|
||||
## Audits documentaires
|
||||
|
||||
Les audits exécutés pendant le fix sont propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (313 file(s))
|
||||
Markdown header audit: clean (286 file(s))
|
||||
Markdown table audit: clean (11 table(s), 286 file(s))
|
||||
Markdown link audit: clean (370 local link(s), 286 file(s))
|
||||
```
|
||||
|
||||
La suite Python n'a pas été rejouée par ce fix de preuve : aucun script ni test n'a été modifié depuis le `55/55 PASS` observé pendant `alpha.1`, et le scope du fix est limité à `VERSION` et à son delta documentaire.
|
||||
|
||||
## Hygiène Git et scope observé
|
||||
|
||||
`git diff --check` puis `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
Le scope indexé observé est exactement :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.fix.1.md
|
||||
```
|
||||
|
||||
Aucun owner normatif, skeleton, template, plan ou document historique antérieur n'a été modifié par le fix.
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-alpha.1.fix.1` est validée `PASS`.
|
||||
|
||||
Le cadrage `0.1.5` est maintenant suffisamment prouvé pour ouvrir `alpha.2`. La tranche suivante reste bornée à la stabilisation de la sémantique `MUST / SHOULD / MAY`, à ses conséquences sur `OVERRIDE` et les gates, et aux quelques renforcements accidentels identifiés par l'inventaire ; elle ne doit commencer ni l'autonomie `alpha.3`, ni la frontière Knowledge `alpha.4`, ni les adoptions Games/KSP.
|
||||
115
history/0.1.5/alpha.1.md
Normal file
115
history/0.1.5/alpha.1.md
Normal file
@@ -0,0 +1,115 @@
|
||||
<!-- file: history/0.1.5/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.1 — cadrage normatif, autonomie et frontière Knowledge
|
||||
|
||||
## Statut
|
||||
|
||||
PARTIAL
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.1` exécutée le `2026-09-30` a acquis toutes les preuves mécaniques effectivement lancées, sans échec observé. Elle reste toutefois `PARTIAL` car plusieurs contrôles explicitement requis par `deltas/0.1.5/alpha.1.md` ne figurent pas dans le transcript opérateur et ne peuvent pas être remplacés par une prévalidation IA.
|
||||
|
||||
Aucun défaut du contenu livré par `alpha.1` n'est établi par les preuves disponibles. La tranche corrective `alpha.1.fix.1` est limitée à l'acquisition des contrôles manquants ; elle ne modifie aucune règle normative et n'absorbe aucun scope de `alpha.2`.
|
||||
|
||||
## Baseline et version observées
|
||||
|
||||
La version observée par l'opérateur est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.1
|
||||
```
|
||||
|
||||
Les contrôles de présence ont confirmé :
|
||||
|
||||
```text
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md présent
|
||||
deltas/0.1.5/alpha.1.md présent
|
||||
history/0.1.5/alpha.1.md absent pendant la gate
|
||||
```
|
||||
|
||||
La chronologie stable précédente a également été relue avec les statuts attendus :
|
||||
|
||||
```text
|
||||
history/0.1.4/alpha.2.md FAIL
|
||||
history/0.1.4/alpha.2.fix.1.md PASS
|
||||
history/0.1.4/rel.1.md PASS
|
||||
```
|
||||
|
||||
## Tests Python observés
|
||||
|
||||
La suite complète a terminé avec succès :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 1.678s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `55/55` tests `PASS` pour les commandes réellement exécutées.
|
||||
|
||||
## Audits observés
|
||||
|
||||
Les audits documentaires et d'hygiène lancés par l'opérateur sont propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (311 file(s))
|
||||
Markdown header audit: clean (284 file(s))
|
||||
Markdown table audit: clean (11 table(s), 284 file(s))
|
||||
Markdown link audit: clean (370 local link(s), 284 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, `git status --short` a affiché :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
M docs/000-README.md
|
||||
?? deltas/0.1.5/
|
||||
?? docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Après l'ajout explicite des cinq chemins de `alpha.1`, le scope indexé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Aucun chemin sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` n'apparaît dans ce scope.
|
||||
|
||||
## Preuves requises non observées
|
||||
|
||||
Le transcript ne contient pas l'exécution des contrôles suivants pourtant présents dans la gate canonique du delta `alpha.1` :
|
||||
|
||||
- assertions `ROADMAP.md` confirmant `0.1.4` terminé, `0.1.5` à `0.1.8` réservés et l'absence de réservation `0.1.9` ;
|
||||
- contrôle d'appariement des `103` couples delta/history historiques et de la frontière du history courant ;
|
||||
- assertions ciblées du prompt `011` sur la sémantique `SHOULD`, l'autonomie et les réservations `0.1.6` à `0.1.8` ;
|
||||
- assertions ciblées du plan `011` sur les `29` fichiers, `242` occurrences et la séparation `alpha.2` / `alpha.3` / `alpha.4`.
|
||||
|
||||
Ces assertions avaient été prévalidées avant livraison, mais cette prévalidation ne constitue pas la preuve opérateur exigée par `docs/rules/400-VALIDATION.md`.
|
||||
|
||||
## Diagnostic
|
||||
|
||||
Le résultat est `PARTIAL`, et non `FAIL` : aucune commande réellement exécutée n'a échoué et aucun défaut de contenu n'est démontré. La limitation vient d'une gate opérateur incomplètement rejouée.
|
||||
|
||||
Le bloc de commandes remis dans le handoff précédent ne reproduisait que les commandes principales alors que le delta contenait une gate plus complète. Le correctif doit donc rester strictement opérationnel et réacquérir les preuves omises sans réécrire le contenu de `alpha.1`.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer/pusher `0.1.5-alpha.1` avec son statut `PARTIAL` avant d'appliquer `0.1.5-alpha.1.fix.1`.
|
||||
|
||||
Le fix suivant :
|
||||
|
||||
- passe `VERSION` à `0.1.5-alpha.1.fix.1` ;
|
||||
- n'altère aucun owner normatif, skeleton, template, plan ou contenu de cadrage ;
|
||||
- rejoue les preuves manquantes et les audits documentaires nécessaires à son propre artefact ;
|
||||
- autorise `alpha.2` uniquement si sa gate obtient réellement `PASS`.
|
||||
|
||||
Aucun commit, push ni résultat de `alpha.1.fix.1` n'est déclaré observé dans le présent history.
|
||||
120
history/0.1.5/alpha.2.md
Normal file
120
history/0.1.5/alpha.2.md
Normal file
@@ -0,0 +1,120 @@
|
||||
<!-- file: history/0.1.5/alpha.2.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.2 — sémantique normative stabilisée
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.2` exécutée le `2026-10-01` est propre. La tranche stabilise `MUST / SHOULD / MAY`, aligne adoption et validation sur cette force normative et corrige les renforcements accidentels ciblés sans convertir mécaniquement les recommandations existantes.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
Le correctif `0.1.5-alpha.1.fix.1` et son history `PASS` ont été committés puis publiés avant application de `alpha.2` :
|
||||
|
||||
```text
|
||||
commit alpha.1.fix.1 32433ca
|
||||
push 90ca422..32433ca master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.2
|
||||
```
|
||||
|
||||
`history/0.1.5/alpha.1.md` conserve `PARTIAL` et `history/0.1.5/alpha.1.fix.1.md` conserve `PASS`. Le history `alpha.2` était absent pendant la gate.
|
||||
|
||||
## Sémantique normative acquise
|
||||
|
||||
Les assertions opérateur ont confirmé dans `RULES.md` révision `15` :
|
||||
|
||||
- `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire ;
|
||||
- un simple écart ne fait pas échouer à lui seul une gate ;
|
||||
- un simple écart n'exige pas automatiquement un `OVERRIDE`.
|
||||
|
||||
`docs/rules/230-ADOPTION.md` révision `2` confirme qu'un choix différent d'un `SHOULD / SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire et qu'un override ne peut pas être exigé uniquement parce qu'une recommandation n'est pas suivie.
|
||||
|
||||
`docs/rules/400-VALIDATION.md` révision `2` confirme qu'un écart à un `SHOULD / SHOULD NOT` PGR ne peut pas, par sa seule force, faire passer une tranche en `FAIL`. Si un projet rend localement ce choix obligatoire, la gate évalue le contrat local explicite et non la recommandation PGR d'origine.
|
||||
|
||||
## Réconciliation ciblée
|
||||
|
||||
Les assertions ont confirmé la réconciliation prévue de :
|
||||
|
||||
- `500-LANGUAGES.md` révision `2` ;
|
||||
- `530-TYPESCRIPT.md` révision `4` ;
|
||||
- `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` révision `4` ;
|
||||
- `700-FRAMEWORKS.md` révision `3` ;
|
||||
- `003-WEB_FRONTEND.md` révision `2` ;
|
||||
- `008-WEB_TYPESCRIPT_PACKAGE.md` révision `3`.
|
||||
|
||||
La référence vivante de l'adoption Games est désormais `0.1.6` et l'ancienne référence `0.1.5` est absente du contrat courant `540`. Les choix JavaScript ou de lockfile différents d'une recommandation ne sont plus transformés en justification ou override obligatoire.
|
||||
|
||||
Le plan `011` révision `2` confirme qu'un écart à une recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique.
|
||||
|
||||
## Frontières et historique
|
||||
|
||||
La ROADMAP conserve :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
0.1.9 non réservé
|
||||
```
|
||||
|
||||
Le contrôle d'appariement a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 alpha.2 history boundary: clean (105 closed prior pairs, current alpha.2 pending)
|
||||
```
|
||||
|
||||
`git diff --exit-code -- history/0.1.4` n'a produit aucun écart : les histories de la stable précédente restent inchangés.
|
||||
|
||||
## Tests et audits
|
||||
|
||||
La suite Python complète est propre :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.855s
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires sont également propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (315 file(s))
|
||||
Markdown header audit: clean (288 file(s))
|
||||
Markdown table audit: clean (11 table(s), 288 file(s))
|
||||
Markdown link audit: clean (370 local link(s), 288 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, le dépôt contenait uniquement les modifications prévues par le delta `alpha.2`. Après indexation explicite, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.2.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/230-ADOPTION.md
|
||||
M docs/rules/400-VALIDATION.md
|
||||
M docs/rules/500-LANGUAGES.md
|
||||
M docs/rules/530-TYPESCRIPT.md
|
||||
M docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
|
||||
M docs/rules/700-FRAMEWORKS.md
|
||||
M docs/skeletons/003-WEB_FRONTEND.md
|
||||
M docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-alpha.2` est validée `PASS`.
|
||||
|
||||
La tranche suivante peut ouvrir `alpha.3`, strictement consacrée à l'autonomie de la baseline locale après instanciation/adoption et au réalignement PGR volontaire fondé sur un snapshot explicitement choisi. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`.
|
||||
121
history/0.1.5/alpha.3.md
Normal file
121
history/0.1.5/alpha.3.md
Normal file
@@ -0,0 +1,121 @@
|
||||
<!-- file: history/0.1.5/alpha.3.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.3 — autonomie locale stabilisée
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.3` exécutée le `2026-10-01` est propre. La tranche établit la baseline locale comme autorité des sessions et releases suivantes après instanciation/adoption et définit tout réalignement futur avec PGR comme une opération volontaire, explicite et bornée.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-alpha.2` et son history `PASS` ont été committés puis publiés avant application de `alpha.3` :
|
||||
|
||||
```text
|
||||
commit alpha.2 e94b786
|
||||
push 32433ca..e94b786 master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.3
|
||||
```
|
||||
|
||||
Les histories précédents conservent la séquence réelle :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
```
|
||||
|
||||
Le history `alpha.3` était absent pendant la gate.
|
||||
|
||||
## Autorité locale acquise
|
||||
|
||||
Les assertions opérateur ont confirmé dans `RULES.md` révision `16` :
|
||||
|
||||
- après établissement de la baseline locale, cette baseline et ses owners deviennent l'autorité des sessions et releases suivantes ;
|
||||
- PGR ne devient pas un upstream documentaire implicite ;
|
||||
- un projet MUST NOT rechercher automatiquement « la dernière version de PGR » ;
|
||||
- un réalignement futur MAY être engagé uniquement comme opération explicite et bornée à partir d'un snapshot PGR précis.
|
||||
|
||||
`docs/rules/220-SKELETONS.md` révision `2` propage ce contrat au point d'instanciation : le projet possède sa baseline locale, ne recherche pas automatiquement une version PGR plus récente et ne revient vers PGR que depuis un snapshot explicitement choisi.
|
||||
|
||||
`docs/rules/230-ADOPTION.md` révision `3` établit le même contrat après adoption et formalise la procédure de réalignement futur : identification du snapshot, comparaison avec la baseline locale et absence de mise à jour automatique.
|
||||
|
||||
## Propagation aux artefacts d'adoption
|
||||
|
||||
Les assertions ont confirmé :
|
||||
|
||||
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : la baseline locale et ses owners deviennent autoritaires après instanciation ;
|
||||
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : le snapshot PGR choisi est explicite, l'autorité après adoption est locale et le réalignement automatique est `non`.
|
||||
|
||||
`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` sont restés `KEEP` comme prévu : leur reprise depuis la baseline autoritaire du projet courant est déjà compatible avec le contrat d'autonomie.
|
||||
|
||||
Le plan `011` révision `3` enregistre `alpha.2 PASS`, les décisions de mise en œuvre `alpha.3` et maintient explicitement la frontière PGR / SaseDev Knowledge en `alpha.4`.
|
||||
|
||||
## Frontières et historique
|
||||
|
||||
La ROADMAP conserve :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
0.1.9 non réservé
|
||||
```
|
||||
|
||||
Le contrôle d'appariement a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 alpha.3 history boundary: clean (106 closed prior pairs, current alpha.3 pending)
|
||||
```
|
||||
|
||||
`git diff --exit-code -- history/0.1.4` n'a produit aucun écart : les histories de la stable précédente restent inchangés.
|
||||
|
||||
## Tests et audits
|
||||
|
||||
La suite Python complète est propre :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.902s
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires sont également propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (317 file(s))
|
||||
Markdown header audit: clean (290 file(s))
|
||||
Markdown table audit: clean (11 table(s), 290 file(s))
|
||||
Markdown link audit: clean (371 local link(s), 290 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, le dépôt contenait uniquement les modifications prévues par le delta `alpha.3`. Après indexation explicite, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M RULES.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.3.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/220-SKELETONS.md
|
||||
M docs/rules/230-ADOPTION.md
|
||||
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
|
||||
M docs/templates/007-EXISTING_PROJECT_ADOPTION.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-alpha.3` est validée `PASS`.
|
||||
|
||||
La tranche suivante peut ouvrir `alpha.4`, strictement consacrée à la frontière PGR / SaseDev Knowledge : taxonomie normative/pratique, auto-suffisance de PGR et suppression de l'ambiguïté « recette Markdown » sans migration physique vers Knowledge et sans dépendance externe.
|
||||
121
history/0.1.5/alpha.4.md
Normal file
121
history/0.1.5/alpha.4.md
Normal file
@@ -0,0 +1,121 @@
|
||||
<!-- file: history/0.1.5/alpha.4.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.4 — frontière PGR / Knowledge stabilisée
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.4` exécutée le `2026-10-01` est propre. La tranche fixe la frontière durable entre le référentiel normatif PGR et les contenus pratiques externes possibles sans créer de dépendance vers SaseDev Knowledge ni déplacer automatiquement de contenu.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-alpha.3` et son history `PASS` ont été committés puis publiés avant application de `alpha.4` :
|
||||
|
||||
```text
|
||||
commit alpha.3 7079b15
|
||||
push e94b786..7079b15 master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.4
|
||||
```
|
||||
|
||||
Les histories précédents conservent la séquence réelle :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
```
|
||||
|
||||
Le history `alpha.4` était absent pendant la gate.
|
||||
|
||||
## Frontière PGR / Knowledge acquise
|
||||
|
||||
Les assertions opérateur ont confirmé dans `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` :
|
||||
|
||||
- les skeletons sont des spécifications Markdown composables et non des recettes pratiques ;
|
||||
- PGR reste auto-suffisant pour comprendre et appliquer ses contrats normatifs ;
|
||||
- les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation peuvent vivre dans une base de connaissances séparée lorsqu'une telle séparation apporte une valeur réelle.
|
||||
|
||||
`docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` confirme qu'un skeleton est une spécification Markdown composable, que SaseDev Knowledge n'est qu'une destination pratique possible et que PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
|
||||
|
||||
`docs/rules/300-DOCUMENTATION.md` révision `5` devient l'owner documentaire de cette frontière :
|
||||
|
||||
- SaseDev Knowledge MAY accueillir des contenus pratiques sans devenir owner normatif de PGR ;
|
||||
- une règle PGR MUST rester compréhensible et applicable sans howto/snippet externe ;
|
||||
- classifier un contenu comme pratique ne déclenche aucun déplacement automatique ;
|
||||
- la séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou un autre dépôt documentaire externe.
|
||||
|
||||
## Owners gelés et trajectoire
|
||||
|
||||
Les contrôles ont confirmé que les owners hors scope de `alpha.4` restent inchangés :
|
||||
|
||||
```text
|
||||
RULES.md version 16
|
||||
docs/rules/210-WORKFLOW.md version 9
|
||||
docs/rules/230-ADOPTION.md version 3
|
||||
```
|
||||
|
||||
`git diff --exit-code` sur ces fichiers, `ROADMAP.md`, `CHANGELOG.md` et `history/0.1.4` n'a produit aucun écart.
|
||||
|
||||
La ROADMAP conserve :
|
||||
|
||||
```text
|
||||
0.1.6 adoption sasedev-games
|
||||
0.1.7 adoption khadhroony-solana-project
|
||||
0.1.8 audits Rust/Clippy read-only
|
||||
0.1.9 non réservé
|
||||
```
|
||||
|
||||
Le contrôle d'appariement a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 alpha.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)
|
||||
```
|
||||
|
||||
## Tests et audits
|
||||
|
||||
La suite Python complète est propre :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.916s
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires sont également propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (319 file(s))
|
||||
Markdown header audit: clean (292 file(s))
|
||||
Markdown table audit: clean (11 table(s), 292 file(s))
|
||||
Markdown link audit: clean (371 local link(s), 292 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, le dépôt contenait uniquement les modifications prévues par le delta `alpha.4`. Après indexation explicite, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.4.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
M docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-alpha.4` est validée `PASS`.
|
||||
|
||||
La tranche suivante peut ouvrir `beta.1` pour la réconciliation transversale des trois contrats stabilisés : rescan des `SHOULD / SHOULD NOT`, vérification de l'autonomie/snapshots/overrides, recherche de références vivantes obsolètes et confirmation que les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` n'ont pas commencé.
|
||||
121
history/0.1.5/beta.1.md
Normal file
121
history/0.1.5/beta.1.md
Normal file
@@ -0,0 +1,121 @@
|
||||
<!-- file: history/0.1.5/beta.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-beta.1 — réconciliation transversale
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-beta.1` exécutée le `2026-10-01` est propre. Elle confirme la réconciliation des trois contrats transversaux stabilisés pendant les alphas sans nouveau défaut normatif démontré : sémantique `SHOULD / SHOULD NOT`, autonomie de la baseline locale et frontière PGR / SaseDev Knowledge.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-alpha.4` et son history `PASS` ont été committés puis publiés avant application de `beta.1` :
|
||||
|
||||
```text
|
||||
commit alpha.4 43ee26b
|
||||
push 7079b15..43ee26b master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-beta.1
|
||||
```
|
||||
|
||||
Les histories précédents conservent la séquence réelle :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
alpha.4 PASS
|
||||
```
|
||||
|
||||
Le history `beta.1` était absent pendant la gate.
|
||||
|
||||
## Réconciliation acquise
|
||||
|
||||
Les contrôles opérateur ont confirmé que :
|
||||
|
||||
- `RULES.md` révision `16` conserve `SHOULD / SHOULD NOT` comme forte recommandation non obligatoire et n'exige pas automatiquement un `OVERRIDE` pour un simple écart ;
|
||||
- `230-ADOPTION.md` révision `3` interdit la recherche automatique de « la dernière version de PGR » et conserve le réalignement comme opération explicite sur snapshot choisi ;
|
||||
- `400-VALIDATION.md` révision `2` interdit qu'un simple écart à un `SHOULD / SHOULD NOT` fasse passer une tranche en `FAIL` ;
|
||||
- `300-DOCUMENTATION.md` révision `5` conserve PGR auto-suffisant et SaseDev Knowledge comme destination pratique possible sans devenir owner normatif ;
|
||||
- `210-WORKFLOW.md` reste en révision `9` et `003-NEW_SESSION_PROMPT.md` en révision `2` ;
|
||||
- la référence vivante Games de `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` pointe vers l'adoption `0.1.6` et l'ancienne référence `0.1.5` est absente de ce contexte vivant ;
|
||||
- Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent réservés tandis qu'aucun `0.1.9` n'est créé.
|
||||
|
||||
Le plan `011` révision `5` enregistre explicitement `alpha.4 PASS`, la réconciliation transversale préparée en `beta.1` et la décision de **KEEP des owners normatifs acquis**.
|
||||
|
||||
## Frontière delta/history
|
||||
|
||||
Le contrôle structurel a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 beta.1 history boundary: clean (108 closed prior pairs, current beta.1 pending)
|
||||
```
|
||||
|
||||
Il confirme que les releases `0.0.1` à `0.1.4` conservent leurs couples delta/history exacts, que les cinq tranches précédentes de `0.1.5` sont closes et que `beta.1` était le seul delta courant sans history pendant sa gate.
|
||||
|
||||
`history/0.1.4` est resté byte-stable pendant la tranche.
|
||||
|
||||
## Freeze des owners
|
||||
|
||||
Le contrôle `git diff --exit-code` sur les owners et artefacts normatifs acquis est propre. `beta.1` n'a donc modifié ni règle normative, ni skeleton, ni template, ni contrat de validation issu des alphas.
|
||||
|
||||
La tranche a uniquement porté la version, la présentation/index, le plan actif et son delta.
|
||||
|
||||
## Tests Python
|
||||
|
||||
La suite complète a affiché :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.892s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `55/55` tests `PASS`.
|
||||
|
||||
## Audit d'hygiène texte
|
||||
|
||||
L'audit réutilisable a affiché :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (321 file(s))
|
||||
```
|
||||
|
||||
## Audits Markdown
|
||||
|
||||
Les audits documentaires sont propres :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (294 file(s))
|
||||
Markdown table audit: clean (11 table(s), 294 file(s))
|
||||
Markdown link audit: clean (371 local link(s), 294 file(s))
|
||||
```
|
||||
|
||||
## Hygiène Git et scope observé
|
||||
|
||||
`git diff --check` puis `git diff --cached --check` n'ont signalé aucune anomalie.
|
||||
|
||||
Après indexation, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/beta.1.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
```
|
||||
|
||||
Il correspond au scope annoncé par le delta.
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-beta.1` est validée `PASS`.
|
||||
|
||||
La phase alpha/bêta est réconciliée sans défaut transversal restant démontré. La tranche suivante peut être `0.1.5-rc.1`, limitée au freeze des contrats acquis, à la présentation candidate, à une revue d'horizon bornée et à la préparation du handoff `0.1.6` uniquement si l'adoption Games reste la prochaine dépendance réelle.
|
||||
133
history/0.1.5/rc.1.fix.1.md
Normal file
133
history/0.1.5/rc.1.fix.1.md
Normal file
@@ -0,0 +1,133 @@
|
||||
<!-- file: history/0.1.5/rc.1.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# PGR 0.1.5 — history `rc.1.fix.1`
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
## Objet
|
||||
|
||||
Clôture opérateur du correctif documentaire `0.1.5-rc.1.fix.1`.
|
||||
|
||||
Le correctif aligne exactement les trois formulations qui avaient fait échouer `rc.1`, sans rouvrir les contrats normatifs, le handoff `012`, la roadmap ou les owners gelés.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-rc.1` avec son history `FAIL` a été committée puis publiée avant application du correctif :
|
||||
|
||||
```text
|
||||
commit rc.1 4d7021b
|
||||
push ec1a296..4d7021b master -> master
|
||||
```
|
||||
|
||||
Une première tentative de `git push origin master` a été interrompue au prompt d'identification puis immédiatement rejouée avec succès. Elle n'a modifié ni le commit ni le contenu de la tranche.
|
||||
|
||||
La version observée pendant la gate du correctif est :
|
||||
|
||||
```text
|
||||
0.1.5-rc.1.fix.1
|
||||
```
|
||||
|
||||
`history/0.1.5/rc.1.md` est présent et conserve le statut réel `FAIL`. Le history du présent correctif était absent pendant la gate.
|
||||
|
||||
## Assertions documentaires corrigées
|
||||
|
||||
PASS :
|
||||
|
||||
- `CHANGELOG.md` est en révision `21` et contient la formulation canonique `forte recommandation non obligatoire` ;
|
||||
- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` est en révision `2` et contient explicitement `aucun numéro de version Games n’est figé` ;
|
||||
- la même étude contient la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` ;
|
||||
- la décision de conserver `0.1.6` comme prochaine release est inchangée ;
|
||||
- aucun `0.1.9` n'est réservé ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` est en révision `7`, conserve la vérité `rc.1 FAIL` et bloque `rel.1` jusqu'au présent `PASS`.
|
||||
|
||||
## Owners et surfaces gelés
|
||||
|
||||
PASS :
|
||||
|
||||
```text
|
||||
README.md version 33
|
||||
ROADMAP.md version 18
|
||||
docs/000-README.md version 52
|
||||
prompts/012-V0_1_6_START_PROMPT.md version 1
|
||||
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` confirme également l'absence de modification des owners, skeletons et templates explicitement hors scope du fix.
|
||||
|
||||
## Frontière delta/history
|
||||
|
||||
Résultat opérateur :
|
||||
|
||||
```text
|
||||
0.1.5 rc.1.fix.1 history boundary: clean (110 closed prior pairs, current rc.1.fix.1 pending)
|
||||
```
|
||||
|
||||
La gate observe donc :
|
||||
|
||||
- toutes les releases `0.0.1` à `0.1.4` avec leurs couples delta/history attendus ;
|
||||
- pour `0.1.5`, les histories de `alpha.1`, `alpha.1.fix.1`, `alpha.2`, `alpha.3`, `alpha.4`, `beta.1` et `rc.1` ;
|
||||
- `rc.1.fix.1` comme seule tranche courante encore sans history pendant sa validation.
|
||||
|
||||
## Tests Python
|
||||
|
||||
Commande :
|
||||
|
||||
```text
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
```
|
||||
|
||||
Résultat :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.898s
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `55/55` PASS.
|
||||
|
||||
## Hygiène texte
|
||||
|
||||
Résultat :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (327 file(s))
|
||||
```
|
||||
|
||||
## Audits Markdown
|
||||
|
||||
Résultats :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (300 file(s))
|
||||
Markdown table audit: clean (11 table(s), 300 file(s))
|
||||
Markdown link audit: clean (375 local link(s), 300 file(s))
|
||||
```
|
||||
|
||||
## Git
|
||||
|
||||
`git diff --check` puis `git diff --cached --check` n'ont remonté aucune anomalie.
|
||||
|
||||
Scope final observé :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/rc.1.fix.1.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
```
|
||||
|
||||
Ce scope correspond exactement au delta prévu.
|
||||
|
||||
## Conclusion
|
||||
|
||||
`0.1.5-rc.1.fix.1` est `PASS`.
|
||||
|
||||
Les trois écarts documentaires de `rc.1` sont corrigés sans changement fonctionnel ou normatif. La candidate est donc éligible à `rel.1`, qui doit rester une promotion stable mécanique sans commencer `0.1.6`.
|
||||
135
history/0.1.5/rc.1.md
Normal file
135
history/0.1.5/rc.1.md
Normal file
@@ -0,0 +1,135 @@
|
||||
<!-- file: history/0.1.5/rc.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-rc.1 — freeze et revue d’horizon
|
||||
|
||||
## Statut
|
||||
|
||||
FAIL
|
||||
|
||||
La gate opérateur de `0.1.5-rc.1` exécutée le `2026-10-01` valide le freeze fonctionnel, les tests Python, les audits documentaires et le scope Git, mais échoue sur trois assertions textuelles exactes prévues par le delta. Le résultat réel est donc `FAIL` malgré l'absence de défaut normatif démontré.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-beta.1` et son history `PASS` ont été committés puis publiés avant application de `rc.1` :
|
||||
|
||||
```text
|
||||
commit beta.1 ec1a296
|
||||
push 43ee26b..ec1a296 master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-rc.1
|
||||
```
|
||||
|
||||
Les histories précédents conservent la séquence réelle :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
alpha.4 PASS
|
||||
beta.1 PASS
|
||||
```
|
||||
|
||||
Le history `rc.1` était absent pendant la gate.
|
||||
|
||||
## Freeze et handoff acquis
|
||||
|
||||
Les contrôles opérateur ont confirmé notamment :
|
||||
|
||||
- `README.md` révision `33` présente la candidate `0.1.5-rc.1` et conserve `0.1.6` comme prochaine release ;
|
||||
- `CHANGELOG.md` révision `20` contient l'entrée `0.1.5 (candidate)` sans chronologie de tranches ;
|
||||
- `ROADMAP.md` révision `18` conserve `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust/Clippy, sans réserver `0.1.9` ;
|
||||
- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` et `prompts/012-V0_1_6_START_PROMPT.md` sont présents ;
|
||||
- le prompt `012` exige une future stable PGR `v0.1.5`, le rapport post-tag uniquement s'il existe réellement avec statut `PASS`, une archive Games autoritaire fournie, puis un intake `0.1.6-alpha.1` avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` ;
|
||||
- `RULES.md`, `210-WORKFLOW.md`, `230-ADOPTION.md`, `300-DOCUMENTATION.md` et `400-VALIDATION.md` restent gelés aux révisions attendues ;
|
||||
- `history/0.1.4` et les owners normatifs stabilisés pendant les alphas restent byte-stables pendant la RC.
|
||||
|
||||
## Assertions en échec
|
||||
|
||||
Trois commandes exigées par `deltas/0.1.5/rc.1.md` ont été exécutées sans produire de correspondance :
|
||||
|
||||
```text
|
||||
grep -F 'forte recommandation non obligatoire' CHANGELOG.md
|
||||
grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
```
|
||||
|
||||
Le shell a poursuivi les commandes suivantes, mais l'absence de sortie sur ces assertions exactes constitue un échec de gate.
|
||||
|
||||
Le diagnostic est documentaire et borné :
|
||||
|
||||
- le changelog exprime la même sémantique avec la formulation « recommandations fortes non obligatoires », mais pas la chaîne canonique attendue au singulier ;
|
||||
- l'étude contient « Aucun numéro de version Games n’est figé... » avec une majuscule initiale, alors que la gate recherche la sous-chaîne en minuscule ;
|
||||
- l'étude présente bien les cinq valeurs de classification dans un bloc, mais ne contient pas encore la forme canonique slash-separated exigée par la gate.
|
||||
|
||||
Aucun de ces trois écarts ne modifie les contrats normatifs acquis ni la décision d'horizon.
|
||||
|
||||
## Frontière delta/history
|
||||
|
||||
Le contrôle structurel a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 rc.1 history boundary: clean (109 closed prior pairs, current rc.1 pending)
|
||||
```
|
||||
|
||||
Il confirme que les releases `0.0.1` à `0.1.4` conservent leurs couples delta/history exacts, que les six tranches précédentes de `0.1.5` sont closes et que `rc.1` était le seul delta courant sans history pendant sa gate.
|
||||
|
||||
## Tests Python
|
||||
|
||||
La suite complète a affiché :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.891s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Soit `55/55` tests `PASS`.
|
||||
|
||||
## Audit d'hygiène texte
|
||||
|
||||
L'audit réutilisable a affiché :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (325 file(s))
|
||||
```
|
||||
|
||||
## Audits Markdown
|
||||
|
||||
Les audits documentaires sont propres :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (298 file(s))
|
||||
Markdown table audit: clean (11 table(s), 298 file(s))
|
||||
Markdown link audit: clean (375 local link(s), 298 file(s))
|
||||
```
|
||||
|
||||
## Hygiène Git et scope observé
|
||||
|
||||
`git diff --check` puis `git diff --cached --check` n'ont signalé aucune anomalie.
|
||||
|
||||
Après indexation, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M README.md
|
||||
M ROADMAP.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/rc.1.md
|
||||
M docs/000-README.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/studies/000-README.md
|
||||
A docs/studies/005-V0_1_5_HORIZON_REVIEW.md
|
||||
A prompts/012-V0_1_6_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-rc.1` est historisée `FAIL` parce que trois assertions contractuelles de la gate ont échoué.
|
||||
|
||||
La correction doit rester limitée à la présentation documentaire et à la traçabilité du correctif. Aucun owner normatif ne doit être rouvert et `rel.1` ne doit pas commencer avant un `0.1.5-rc.1.fix.1` validé `PASS`.
|
||||
150
history/0.1.5/rel.1.md
Normal file
150
history/0.1.5/rel.1.md
Normal 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`.
|
||||
87
prompts/012-V0_1_6_START_PROMPT.md
Normal file
87
prompts/012-V0_1_6_START_PROMPT.md
Normal file
@@ -0,0 +1,87 @@
|
||||
<!-- file: prompts/012-V0_1_6_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompt de démarrage 0.1.6 — adoption réelle de PGR par sasedev-games
|
||||
|
||||
## Baselines et cible
|
||||
|
||||
Dépôt canonique PGR : `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
La baseline PGR attendue au démarrage effectif de `0.1.6` est l’archive source téléchargée depuis le tag Gitea `v0.1.5`, accompagnée du rapport post-tag `pgr-0.1.5-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
|
||||
|
||||
La session doit également recevoir une archive récente et explicitement autoritaire de `sasedev-games`. Le présent prompt ne fixe volontairement aucun numéro Games : utiliser la baseline réellement fournie et ne pas reconstruire une version depuis d’anciens documents PGR.
|
||||
|
||||
Version cible PGR : `0.1.6`. Première tranche attendue : `0.1.6-alpha.1`.
|
||||
|
||||
Une archive source de tag peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu’elle ne peut contenir.
|
||||
|
||||
## Mission
|
||||
|
||||
Exercer réellement le modèle d’adoption PGR contre `sasedev-games`, sans transformer PGR en upstream permanent du projet et sans généraliser les décisions propres à Games.
|
||||
|
||||
L’objectif est de produire une cartographie explicite `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, puis de matérialiser uniquement les changements réellement justifiés dans la baseline locale Games.
|
||||
|
||||
La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/005-V0_1_5_HORIZON_REVIEW.md`](../docs/studies/005-V0_1_5_HORIZON_REVIEW.md).
|
||||
|
||||
## Intake obligatoire
|
||||
|
||||
Avant toute modification :
|
||||
|
||||
- vérifier intégralement la stable PGR `v0.1.5` et le rapport post-tag réellement fourni ;
|
||||
- vérifier intégralement l’archive Games fournie et identifier sa version/baseline autoritaire réelle ;
|
||||
- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md`, `300-DOCUMENTATION.md` et `400-VALIDATION.md` ;
|
||||
- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` et les profils techniques réellement applicables au corpus Games observé ;
|
||||
- relire le plan historique `011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` et la revue d’horizon `005-V0_1_5_HORIZON_REVIEW.md` ;
|
||||
- vérifier les deltas/histories `0.1.5` sans réécrire la vérité opérateur, notamment `alpha.1 PARTIAL` puis `alpha.1.fix.1 PASS` ;
|
||||
- vérifier que la première tranche préparée est bien `0.1.6-alpha.1`.
|
||||
|
||||
## Contrat d’adoption
|
||||
|
||||
L’audit doit classifier chaque écart réellement pertinent :
|
||||
|
||||
```text
|
||||
ADOPT règle/artefact PGR retenu pour la baseline locale Games
|
||||
KEEP-LOCAL décision Games existante conservée comme autorité locale
|
||||
OVERRIDE contradiction réelle et documentée avec un MUST PGR applicable
|
||||
DEFER sujet potentiellement applicable mais non justifié dans le scope courant
|
||||
N/A owner/profil non applicable au corpus Games observé
|
||||
```
|
||||
|
||||
Un écart à un `SHOULD / SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` et ne doit pas être traité comme une non-conformité.
|
||||
|
||||
Ne pas forcer l’adoption d’un profil uniquement parce qu’il existe dans PGR. L’applicabilité doit être démontrée par la baseline Games réellement fournie.
|
||||
|
||||
## Autorité locale après adoption
|
||||
|
||||
PGR sert de snapshot de comparaison et d’adoption. Une fois la baseline locale Games établie, cette baseline et ses owners deviennent l’autorité des sessions/releases suivantes de `sasedev-games`.
|
||||
|
||||
Les sessions Games ultérieures ne doivent pas rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream documentaire permanent.
|
||||
|
||||
Un futur réalignement reste possible uniquement comme opération explicitement décidée à partir d’un snapshot PGR précis.
|
||||
|
||||
## Préservation du contexte Games
|
||||
|
||||
Les décisions produit, architectures métier, POCs et contraintes propres à Games restent locales lorsqu’elles ne relèvent pas d’un contrat PGR générique.
|
||||
|
||||
Ne pas promouvoir automatiquement un ancien POC, une technologie historique ou un artefact expérimental au rang de surface produit/applicable. La baseline Games fournie doit démontrer son rôle courant.
|
||||
|
||||
Ne pas supprimer ou réécrire une décision locale uniquement pour obtenir une symétrie avec PGR.
|
||||
|
||||
## Hors scope
|
||||
|
||||
`0.1.6` ne doit pas :
|
||||
|
||||
- commencer l’adoption de `khadhroony-solana-project`, réservée à `0.1.7` ;
|
||||
- commencer les audits Rust/Clippy read-only, réservés à `0.1.8` ;
|
||||
- rouvrir les contrats transversaux de `0.1.5` sans contradiction réelle démontrée par l’adoption Games ;
|
||||
- rendre Games dépendant de PGR ou de SaseDev Knowledge ;
|
||||
- généraliser dans PGR des choix Games uniquement parce qu’ils sont présents dans le corpus ;
|
||||
- fabriquer un corpus, une version Games ou une preuve runtime absente de l’archive fournie.
|
||||
|
||||
## Première tranche attendue
|
||||
|
||||
`0.1.6-alpha.1` doit être une tranche d’intake et de cartographie : vérifier les deux baselines, inventorier les surfaces Games réelles, déterminer les profils PGR applicables, produire la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, proposer le plan de release et identifier les owners exacts à modifier.
|
||||
|
||||
Elle ne doit pas effectuer une migration massive avant cette cartographie.
|
||||
|
||||
La validation doit rester proportionnée au corpus Games réellement applicable et conserver séparées les preuves PGR, les preuves Games et les décisions d’adoption.
|
||||
Reference in New Issue
Block a user